bugmldonkey, a multi-networks file-sharing client - Bugs: bug #10770, No response from core (when too...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #10770: No response from core (when too many sources are available?)

Submitted by:  PJ CLEMENCEAU <pjc>
Submitted on:  Fri 22 Oct 2004 06:58:34 PM UTC  
 
Category: CoreSeverity: 3 - Normal
Item Group: Program malfunctionStatus: Fixed
Assigned to: NoneOpen/Closed: Closed
Release: 2-5-16Release: 2-5-16
Operating System: Mac OS X 10.3Binaries Origin: CVS / Self compiled
CPU type: PowerPC

(Jump to the original submission Jump to the original submission)

Tue 12 Apr 2005 10:01:38 AM UTC, comment #8:

Current MLDonkey versions (>2-5-30) along with current Ocaml version (>3.08.2+4) fix this bug.

spiralvoice <spiralvoice>
Project Administrator
Mon 04 Apr 2005 09:34:37 PM UTC, comment #7:

Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://download.berlios.de/pub/mldonkey/spiralvoice/

spiralvoice <spiralvoice>
Project Administrator
Mon 21 Mar 2005 07:41:12 PM UTC, comment #6:

HELLO?!?!?!?!? ANYONE!?!?!?!?!?!?!??!?!?!?!?!?!?!?!?!?!?!?!??!?!???!?!?!!!?!?!?!?

Anonymous
Wed 16 Mar 2005 09:34:33 PM UTC, comment #5:

Any updates on this??!?? This is getting maddening!

Anonymous
Mon 15 Nov 2004 01:41:13 PM UTC, comment #4:

I have had the same problem for a long time, and ulimit is not a solution (it's "unlimited" on my platform - mac os x). But I've investigated the problem a bit further and found 3 linked phenomenons :
- the mlnet process takes more and more cpu time (until I have 0% idle using top)
- the interface (html or telnet) becomes less and less responsive (and eventually ends up not responding at all)
- and MOST IMPORANT : the number of "dead" connections constantly grows (i can see that using netstat, fstat, or lsof)

My workaround, until now, has been to write a "mldonkey_watch" shell script which monitors the daemon's behaviour based on 2 criterias :
- number of dead connections - I decide to restart the core when it reaches 200
- reactivity of the core to commands via telnet (actually netcat) - I consider mlnet is hung when it doesn't respond for one minute
- I didn't figure out yet how to monitor cpu usage (which I think is a side effect)

Then I send a "kill" command to mlnet, wait one more minute, and if it was ineffective, kill the process the unix way.

I have to add that this misbehaviour of mldonkey (I'm only using the edonkey protocol) used to cause kernel panics in my system (which were located in the driver of my pci - dsl modem). And since I have mldonket monitored, my system has regained an impressive stability !

I nevertheless think this issue should better be fixed...

Anonymous
Sun 24 Oct 2004 07:21:54 PM UTC, comment #3:

I have tried using ulimit. Doesn't help.
The only item I have currently perform that seems to help (but still end up in the end with no response) is to limit the number of servers to 2 and suppress auto-refresh of servers list. It actually limits a little the number of available sources, thus giving more time....

PS : one other point : altough the web interface fails, the telnet interface, if launched from the start, continues to work.
This gives me the following results : when core "stops" responding, actually some downloads continue for some time, then slowly drop out, and then no new download come in, the core just sits "waiting". If I kill it and relaunch it, it automatically finds new sources and will perform new downloads... and in the end once again stop responding.

PJ CLEMENCEAU <pjc>
Sat 23 Oct 2004 03:25:56 PM UTC, comment #2:

100% agreed, also in -28h with BT

Hansi Husten <HansiHusten>
Fri 22 Oct 2004 10:25:45 PM UTC, comment #1:

Try raising limits for mlnet using ulimit

spiralvoice <spiralvoice>
Project Administrator
Fri 22 Oct 2004 06:58:34 PM UTC, original submission:

After a few hours (2 or 3), I get no response from the core when using the html or telnet interface.
This happens since I have been trying to dl a file that has numerous sources (>4000), and also for which I get more than 100 ul requests.

A hinch may come from the following message, that I get when trying to access options page, and usually this message appears shortly before "failure". Message is : "Exception opendir failedon ./html_themes: Too many open files"

PJ CLEMENCEAU <pjc>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Tue 12 Apr 2005 10:01:38 AM UTCspiralvoiceOpen/ClosedOpen=>Closed
Tue 05 Apr 2005 10:37:05 AM UTCamorphousStatusNone=>Fixed

Back to the top


Powered by Savane 3.1-cleanup1