... I suppose I shouldn't have 1077 threads open too... This is with one big dl going on, some uploads and running as UP with saturday CVS version. 185 MB ram and 1.09 GB VM. Want the threads samples Sam?

I doubt the threads made much difference: I had very little transfers yesterday (1/2 GB up and down; mostly gnutella traffic as an UP)

Salut Stief! A thread isn't using much memory at all, but LW sould close the threads nonetheless. It has an impact on the computer performance at some point ... now 1138 threads open.

Ciao

salut et voilà -- and a happy new year to you.

I'll take another look at the thread count here (with whatever beta is officially released), and see if that might help spot something.

cheers

You're correct -- unless you've got a massive amount of downloads going on, there shouldn't be that many threads. (There should be around 10-25 threads if a leaf and 80-120 if an ultrapeer.)

The best way to get a sample, though, is to get the Java thread names & stack traces. To do this, open up Terminal, Console, and Process Viewer. In Process Viewer, click on 'LimeWire' and note the 'Process ID' listed at the bottom. Then, in terminal, type 'kill -QUIT <the process id>'. Stuff should then be printed out in Console. If you can copy that here (or if you want, email to me at sberlin@limepeer.com ), that'd be very helpful.

Thanks.

Since I often download very rare files, I also have very many downloads a lot of times, and when I have more than 200 downloads, computer performance really goes down, so I think it woould be a good Idea to use single threads only for downloads which are either queued or actively downloading (If that is possible).

Humm I did the command on the com.limegroup.gnutella.gui.Main (CVS build) but nothing showed in console. I tried the command on textedit, but no console log too. Here what I typed:

kill -QUIT 4330

Any help appreciated...

Here is the sample I got earlier:

LimeWire handles all inactive downloads with a single thread since LimeWire 4.1.2. Previously, every single download required it's own thread to manage itself. Active downloads, however, require a thread for management and another thread for each source. There's no way around that, just yet.

We're in the process of upgrading the network to Java 1.4 (part of what our new installer is planned to do). Once that happens, we can begin to design using what's called "non-blocking I/O" -- that means we can send & receive information asynchronously -- without having to dedicate a resource just to sending (and waiting till it was sent) & receiving (and waiting till something was received).

We had always intended to add NIO before, but the complexity of having to design for both blocking & non-blocking streams always stopped the project from being finished. Using Java 1.4, we can design strictly for NIO (not to mention use lots of other great Java 1.4 features).

kill -QUIT produces output when used on Java processes. Are you seeing excess threads with the Beta or with CVS? The two are pretty similiar right now, but have very different ways of launching (which might be contributing to problems).

Using CVS from yesterday, LW shows up as com.limegroup.gnutella.gui.Main in process viewer. I used kill -QUIT, but it only made disapeared the LW interface (the menu bar was still there). I really killed the process with the kill -KILL command.