Likely network disconnect reconnect
Why am I getting 'Likely network disconnect/reconnect: Repairing 1 selector, xx keys' alerts?
That message is shown when network socket selector spin is detected, and it's pretty hard to trip it off without there actually being a problem; i.e. false positives are extremely rare. Without getting into specifics, a socket selector is a high-speed way of knowing when a socket is ready to be written to / read from ( ala poll() ). In this case, to warrant a popup alert, a select op would have to return, prematurely, without having selected any channels for readiness 10,000 times in a row. If this happens consistently, something is most definitely wrong.
- This detection was added because under Windows, under JRE 1.4 series in particular, when the underlying os network transport was reset (say, when the network cable is unplugged and then replugged), it caused the selector to spin profusely, causing 100% cpu issues. Upgrading to java JRE 1.5 series should solve this problem.
- NOD32 Antivirus is known to cause this problem as well. You should uninstall it, or disable the monitoring (IMON) to fix. See ConfiguringNOD32.
- Norton Personal Firewall, Zone Alarm, or any other network monitoring software can cause the alerts.
- Some operating system network stacks and/or network drivers do not play nice with the java JRE and can cause the problem as well. There are several reports of this happening occasionally under linux and older versions of Windows.
- Using NetLimiter may also cause this problem. Try closing NetLimiter and restarting Azureus.
- POSSIBLE CAUSE! I started looking at this problem and after a little debugging I managed to determine that, at least for Solaris, I am only seeing the problem in ConnectDisconnectManager. So I did some searching and found some clues on the Java Forums http://forums.java.sun.com/ . I took a closer look at the docs for java.nio.channels.SocketChannel, which states for the connect() method "If this channel is in non-blocking mode then an invocation of this method initiates a non-blocking connection operation. If the connection is established immediately, as can happen with a local connection, then this method returns true. Otherwise this method returns false and the connection operation must later be completed by invoking the finishConnect method." Looking at the code for ConnectDisconnectManager.java, I found that the return code for the connect() method is ignored. So I put a debugging statement in to show the value, and sure enough, when connect() returns true, I see the DisconnectReconnect alert. I believe I have implemented a fix, but I don't see anywhere here to attach files.
- I have found this problem with Java 1.5 version 3 on RH9 linux 2.4.20-20.9, on a 450MHz Pentium III with 128MB RAM, using a USB 1.0 disk for the download data folder. Possibly low ram and thrashing causing a problem?
- I have this problem on SuSE 9.2 on an Athlon 2000, 768MB RAM so I don't think RAM or thrashing is the cause.
- I have a one-way cable modem which causes this problem when uploading. Sometimes I get latencies of a second or more. Could there perhaps be added an option to disable this?
- I have the same problem with Java 1.5_03 on Fedora Core 3. I don't think RAM or CPU's are an issue here since I have 3.2 P4/HT and 2 gigs of RAM
- I got this problem from 188.8.131.52 on Sun Java 1.5.0-b64 on Gentoo. The machine is a PIII-550 with 396MB RAM. I didn't have the message at midnight, but it was there at 7:00am this morning. I checked my MRTG graphs for oddities, and noticed all of the following from 12:45-1:30 this morning: Load went through the roof (was hanging around .8, went up over 5 -- the graph cap), download rate dropped from 200KB/s to 30KB/s and took an hour to ramp back up afterwards, swap used went from 150MB to 500MB in about 30 minutes. My guess would be the excessive swapping slowed the whole machine down enough to cause the problems. By 7:00 this morning, all the other graphs have returned to normal, but I'm still using over 500MB of swap. According to the 'Azuerus Monitoring Plugin', Azuerus is only using 42MB of heap, and 26.7MB of non-heap memory. According to my OS, Azuerus's Java process is using 281MB of memory.
- I'm seeing a similar situation to the user above on Gentoo for amd64 with Blackdown JRE 1.4.2.01 (64-bit). This morning my Azureus Java process has a virtual size of about 1.6 GB and a resident size of over 100 MB. Together with a couple of Firefox instances, this is pushing my machine pretty heavily into swap (about 700 MB on top of my 1 GB RAM, which is almost completely used).
- I see the message too (Azureus 184.108.40.206/Gentoo/AMD64); but I've also seen Azureus claiming a disconnect while incoming UDP messages were piling up in the input buffer... Could it be a race condition or incorrect error handling?
- I am getting this error running WinXP/AMDXP I only get this error when upgrading from 2.2.X.X to 2.3.X.X I'm not seeing any heavy RAM or PF usage, just the error popping up constantly and poor download speeds.
- I get this error very frequently on the linux-gtk azureus version 220.127.116.11 (and earlier versions) with JRE 1.5 on fedora core 3. Also, these warning windows can pile up quite deep in a short time and they are, for no obvious reason, displayed on all virtual workspaces, not just the one in which azureus runs.
- I got it once, when downloading to a location across a 100mbit LAN while the network was under some stress, while the measly 1.15ghz, 256mb DDR system was transcoding video. I guess I deserved it.
- I got this message and non-connecting torrents on Linux because the default Java runtime in my PATH was the one of Matlab 7. I dropped the Matlab Java runtime from my path and the default system runtime was used, making Azureus work.
- I hate to say a me too... but, me too. I'm running FC3 with jre 1.5.0_03 and have recieved this error. I'm running with 1Gig of ram, and, as above, there are large disparities between what Azureus says the memory usage is and what the kernel says the memory usage is. I think this may be a symptom of a larger problem.
- I can also confirm this happening on Solaris 10 (x86 and amd64) when upgrading from 2.2 to 2.3. This message is frequent, and results in Azureus unable to download or upload. I have not yet determined the cause, and have since returned to 2.2.
- Running Windows 2000 with all patches. Using jre 1.5.0_03. Got this with Azureus 18.104.22.168. I figured out that it happens when I use net limiter to shape my traffic outside of Azureus. I've been using Net Limiter forever and this only became a problem with 22.214.171.124.
- Also experiencing the problem with Net Limiter. This is unfortunate because I like to run Net Limiter to limit bandwidth from time to time when using VOIP, which can get flooded out by Bittorrent activity. This way I don't have to stop Azureus downloads when the phone rings.
- I am having this problem on an Ubuntu 5.04 on an amd64, using JRE 1.5.003 and latest Azureus. VERY frustrated. Please help if you have a solution. 6/26 UPDATE: I upgraded to JRE 1.5.004 and I STILL have these problems. UGH! :( UPDATE 6/30 Upgrading Azureus to version 126.96.36.199 fixes the problem!
- I am using a 1.6Ghz system with slow RAM. Anyway I have never seen this happen until I started using 188.8.131.52 (was using 2.2.x.x before). I think it's related to high cpu usage because it happened after I was using an emulator for a minute.
- I got this message while using winRAR to RAR a 4 gig file (high CPU usage). Never seen B4. P4 2Ghz 512mb 184.108.40.206 Jre 1.5.0 XP_pro.