Gnutella Forums - beta 4.9.4 dropping connections

Gnutella Forums (https://www.gnutellaforums.com/)

- LimeWire Beta Archives (https://www.gnutellaforums.com/limewire-beta-archives/)

- - beta 4.9.4 dropping connections (https://www.gnutellaforums.com/limewire-beta-archives/41165-beta-4-9-4-dropping-connections.html)

That makes some amount of sense. It was my own hypothesis -- the only legitimate reason for it to try to contact ebay that I could think of.

The real question is: why was it unable to establish a connection, when the web browser, MSN messenger, and other network apps were working OK? I suppose the incorrect firewall detection has something to do with it...

I've configured my copy of limewire not to try to use UPnP to detect a router or firewall since I know darn well there is none and I know autodetect anything is a headache waiting to happen. Unfortunately, it seems to ignore that setting and sometimes tries to autodetect a firewall anyway, resulting in the inevitable headache: it detects a phantom firewall that doesn't exist, chokes, and dies. :P

The incorrect firewall detection is a byproduct of not being able to access the internet. Every so often, LimeWire will 'forget' its firewall detection status and re-detect. If it isn't able to make or take any connections, the redetection shows as firewalled. But yes, the original "why can't it make connections" still stands.

Quote:

Originally posted by jum
So how does one get one of these under Windows if one starts using LimeWire.exe? I know how to generate them on Unix, but on Windows I have never done it.

I'm not sure you can get one with LimeWire.exe, but if you do start limewire from the command prompt with "java -jar ..." you can get a trace with Ctrl-break (or just break? someone correct me here pls)

You can download LimeWireDebug from http://www.limewire.org/LimeWireDebug.exe . It'll open a DOS-box when you run LimeWire, which'll contain anything printed to stderr or stdout. It won't have logging, though.

Well , there so many threads running that I cannot record the complete stack trace as it overflows my console scroll back buffer. But I have so many Timeout guards running that I would believe that these must have a problem somewhere:

Code:

"Timeout guard" daemon prio=5 tid=0x02d40910 nid=0x1034 runnable [0x0a7cf000..0x

0a7cfa68]

        at java.net.PlainSocketImpl.socketConnect(Native Method)

        at java.net.PlainSocketImpl.doConnect(Unknown Source)

        - locked <0x23edfae0> (a java.net.SocksSocketImpl)

        at java.net.PlainSocketImpl.connectToAddress(Unknown Source)

        at java.net.PlainSocketImpl.connect(Unknown Source)

        at java.net.SocksSocketImpl.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.c

reateSocket(DefaultProtocolSocketFactory.java:105)

        at org.apache.commons.httpclient.HttpConnection$1.doit(HttpConnection.ja

va:697)

        at org.apache.commons.httpclient.HttpConnection$SocketTask.run(HttpConne

ction.java:1333)

        at java.lang.Thread.run(Unknown Source)
 

"Timeout guard" daemon prio=5 tid=0x032526a0 nid=0xb10 runnable [0x0a44f000..0x0

a44fc68]

        at java.net.PlainSocketImpl.socketConnect(Native Method)

        at java.net.PlainSocketImpl.doConnect(Unknown Source)

        - locked <0x23edee28> (a java.net.SocksSocketImpl)

        at java.net.PlainSocketImpl.connectToAddress(Unknown Source)

        at java.net.PlainSocketImpl.connect(Unknown Source)

        at java.net.SocksSocketImpl.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.c

reateSocket(DefaultProtocolSocketFactory.java:105)

        at org.apache.commons.httpclient.HttpConnection$1.doit(HttpConnection.ja

va:697)

        at org.apache.commons.httpclient.HttpConnection$SocketTask.run(HttpConne

ction.java:1333)

        at java.lang.Thread.run(Unknown Source)

Ah, good - if there was a deadlock it would be the last thing printed on the console.

Btw the stack trace is printed on stdout, so you can redirect it to a file should this happen again.

Thanks a lot jum! If you can give it one more try with stdout redirected we'd nail this one down :)

Well this is something new -- LW 4.9.4 perpetually stuck at three green bars, two red. It's been this way for at least half an hour. For some reason it is either unwilling or unable to restore the remaining two connections.

@Shinsengumi

Do downloads work?

No -- they reach 20% or so and "await sources", just like always. So no change there. ;P Anyway it spontaneously recovered after an additional half hour and I went on to get a few files (and add a lot more "awaiting sources" items to the list).

OK, this time I got all the stack traces in one file. You can find it at:

http://baghira.han.de/~jum/stack.log