[Mldonkey-users] mldonkey logs

[vaab]

hi all,

I posted recently on the "no connection to edonkey server". I've
deactivated BitTorrent (that i was not currently using), and it
changed nothing. But i caught mldonkey this morning donwloading
at 30Ko/s that is really really a great news.

Explications of this incredible rate ? : i can't remember when i took
the 2.5-4 version, and i might be using the "old" 2.5-4... So i've got
the latest CVS the 16 October in the evening. And it might be a new
version.

I really think it is important that the max_concurrent_download should 
be lowered at 30. It seems to stop the uses of the RAM to less than 100 
Mo AND leave bandwith for downloads...

Well, this is not all : willing to dig into the "no connection to
edonkey server" a little bit, I glanced toward the mldonkey logs. I
havn't got anything to manage my logs, so they are just growing and
growing. I nearly fainted at the view of the number displayed in the
'size' field of the good old 'ls -l'. This was a 5 with too much digit 
after... I didn't count exactly, as I thought of my poor left space, and 
acted quick for the removal of the file. It was 500 Megs or more, but i 
don't know if 5 Gigs is possible...

Well, i looked in the never-stopping stream of logs that mldonkey throw
in his logs and caught 90% of this :

------------------------------------
set_reader for
set_reader for
set_reader for
set_reader for
redirector recontacted in 33 seconds
set_reader for
set_reader for
redirector recontacted in 32 seconds
set_reader for
set_reader for
set_reader for
------------------------------------

with an average rate of 5 to 12 line per seconds... 300 000 lines in 
less than 12 Hours... 8 Megs of log in less than 12 Hours !!

I think this could be easily patched... And a lot of useless log entrie 
would be taken out : In my less-than-12-Hours-old log i've :

177 000 lines of 'set_reader for'
 42 000 lines of 'redirector recontacted in xx seconds'
 89 000 lines of others things...

well, if all this can help...

vaab

PS : well, with these stats, it seems the log files did *only* 500 Megs.