So the output we have on the machine here says build 1.4.1_01-39.

That look old enough to be the released version? I'd just like to make sure we're testing on the generic java 1.4 that is available through software update.

That appears to be the release version. Just the two versions exist, Apple has not issued any other releases of the 1.4 JVM.

FWIW, on my stock G4 iMac running OS 10.26 java -version returns:[If it would help, I'd been planning an erase and install of the G3, which has the current DP version. Let me know and I'll get busy sooner].

Glad to hear LW using the beta forum to taking these careful steps.]

GUI freezing
 

Hi Jen, I get it pretty random it seems, sometimes when I'm playing with the user interface and the rest of the time, I do not interact with it when it happens. For exemple, yesterday I left LW runnning hidden (command-H). This morning when I first saw that the processor was at 100%, I knew the gui froze. When clicking on it the beach ball appeared, and I had to foce quit it from the dock (before quitting it I ran an utility that told me that LW was still uploading full speed fine). When I forced quite it, it crashed. I'd like to show the crash log, but the last crash logged in limewire in the history of the console is 28 august....

Adam: I noted that on my system (iMac g3 512 mg ram) that LW uses nearly two times the amount of physic memory in java 1.4 than with 1.3. (90megs versus 50megs)

I know debugging is hard ans frustrating, but keep rollin'!

Merci de votre patience

I would say if you could run LimeWire on your unmodified box for a few days and report your findings that would help.

Re: GUI freezing
 

From that description I would assume that is with the original 1.4 JVM? I remember seeing something similar, but I did not see it again using DP102.

Hmm, for me 90 megs resident set size (I assume this is what you mean with physical memory) as seen in top is small, I see LimeWire taking around 160 megs.

Wait a sec, I have an idea what could cause the GUI freeze. Do you have the bug reporting option set to always send? If not, set the config to always send.

Currently under OS X LimeWire does produce an out of memory bug every once in a while (actually quite often for me) that does not appear to impact operation much. But if the bug report is not send, it will popup a dialog box asking for what do. These dialog boxes will stack up and lots of them will make the OS X gui so slow as to appear frozen. Check if setting the bugs setting to always send fixes your freeze. if yes it is the stacking dialog problem.

Bonne soirée, Jens, thanks for the replies!

The gui freezes came the same way in regular java 1.4 and DP102 java, minus that with DP102 it seems to take more time to happens. With regular 1.4, it happens within the hour.

On the memory side, this is the resident memory with process viewer and this does not include virtual memory (I don't care about this stat, too depressing... ;) right now near 300megs with freshly started LW basic 3.4.7).

On the always send bug, since the apparition of the option it was checked at always send....

Merci

Stief remembered me that I did recommend one config change in the past: tuning OS X for server use. For this to work you will need to add a line like this to /etc/hostconfig:

SERVER=-YES-

if this is not already in your hostconfig. Upon the next boot OS X will adjust the internal tables for server use, that means more processes, threads and open files.

Hi Jens
Is webserver=-yes- the same as server=yes ? I have the webserver already enabled on my machine.

Merci