From the code in the Sun InetAddress class I would say that networkaddress.cache.ttl is the property to set. I just started a LimeWire with this property set to 300 seconds, I will report if this makes any difference.

I think it good, that filenames can't be edited that simple anymore. I always did it unintentionally, even for the folders...

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

It did not make a difference, LimeWire still grows in memory usage while running. So it is not the address cache.

>Edit file names;

This was done purposely. Too many people were accidentally changing the names of files/folders. It will be re-added if we can make the editor act in an expected manner, rather than going into editing mode at strange and confusing times.

>Drag files into sub-folders.

This was also removed purposely, as the entire Drag & Drop system is being redesigned to use Java's built-in system instead of our hand-crafted one. Dropping will (hopefully) be re-added before 4.2 is released.

I am on mandrake 10 Official and upon first run, I was told that DAAP for sharing in iTunes was unable to start and would be disabled.

I have not used juk, but I don't believe it has iTunes sharing. If this is the case, you can probably just skip this prompt if OS=linux.

Not a big deal, but I figured I'd point it ouf just in case it was an oversight.

The DAAP error on Linux is already fixed for the next beta, with much thanks to Roger Kapsi. Not sure what 'juk' is though.

Well I've investigated the memory problem a little bit more... Uploads of simultaneous 700 megs files for ten hours computer unattended without downloads resulted in 22(!!!) megs RAM and 800 megs of virtual memory. LW was in idle state (1 UP connection). Now that I use the computer LW mem usage grew to 53 megs ram and 800 megs virtual memory. So 2 more connections = 31 megs RAM (???) As for the 200 megs ram I reported earlier, the same uploads were coupled with 1 download (a 200 meg file). Could there be a memory leak in the download code (a big one) and in connections (a smaller one)?

Ciao

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

Which tool do you use to gather the numbers? I suppose "top" and you're referring the VSIZE column?

Process viewer, of course

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

Strange, - I don't see LimeWire ever use that much memory...