Bug 187103 - Azureus transfers do not maintain speed
Azureus transfers do not maintain speed
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: azureus (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anthony Green
Fedora Extras Quality Assurance
:
: 206078 (view as bug list)
Depends On: 200196
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-28 10:33 EST by Andy Burns
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-11 16:28:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch (625 bytes, patch)
2006-07-09 10:02 EDT, Anthony Green
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 23682 None None None Never

  None (edit)
Description Andy Burns 2006-03-28 10:33:24 EST
Description of problem:
Torrent downloads using azureus start off ok, taking a little while to reach
full speed of my ADSL line, I see this as the normal process of "joining" a
torrent, but after perhaps an hour of transferring the speed (both upload and
download) tails off to zero or a few bytes per second, it only seems to recover
by exiting and reloading, merely stopping and re-queueing a torrent inside
azureus has little or no effect.

Sometimes when exiting, azureus fails to respond and needs to be forcibly
closed, others have reported that if you wait a *long* time it does eventually
close, I'm obviously impatient.

Version-Release number of selected component (if applicable):
azureus 2.4.0.0-0.20060209cvs_1.fc5
kernel 2.6.16-1.2069_FC5
gij 4.1.0-3

How reproducible:
Most of the time, it has good spurts and slow troughs, so to speak.

Additional info:
Have tried to eliminate other causes by throttling upload rate, opening firewall
tcp/udp ports, leaving torrents seeding, changing to ports other than 688X

Turning on logging I've captured the following exceptions, which occur once a
second or so, I noticed that the "log to file" options didn't seem to function.

[3:31:19.934] {stderr} DEBUG::Tue Mar 28 15:31:19 GMT
2006::com.aelitis.azureus.core.networkmanager.VirtualChannelSelector::select::-1:
[3:31:19.935] {stderr}   Caught exception on selector.select() op: 5
[3:31:19.936] {stderr}    
ReadController::readSelectorLoop::-1,ReadController::access$0::-1,ReadController$1::runSupport::-1,AEThread::run::-1
[3:31:20.000] {stderr} java.lang.ArrayIndexOutOfBoundsException: 5
[3:31:20.001] {stderr}    at gnu.java.nio.SelectorImpl.getFDsAsArray (libgcj.so.7)
[3:31:20.002] {stderr}    at gnu.java.nio.SelectorImpl.select (libgcj.so.7)
[3:31:20.003] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.VirtualChannelSelectorImpl.select
(Azureus2.jar.so)
[3:31:20.003] {stderr}    at
com.aelitis.azureus.core.networkmanager.VirtualChannelSelector.select
(Azureus2.jar.so)
[3:31:20.003] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController.readSelectorLoop
(Azureus2.jar.so)
[3:31:20.004] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController.access$0
(Azureus2.jar.so)
[3:31:20.004] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController$1.runSupport
(Azureus2.jar.so)
[3:31:20.005] {stderr}    at org.gudy.azureus2.core3.util.AEThread.run
(Azureus2.jar.so)
Comment 1 grant petersen 2006-04-02 00:39:26 EST
I have the same thing going on. The download starts seeming OK but slows to
nothing after a variable period.
On restart the torrents are fine for a while but never long enough to be useful. 
Stopping a torrent in Azureus will sometimes result in a torrrent sticking with
the status stuck on "Stopping". When this happens Azureus can not be closed and
has to be killed.

My system;
Arch:    i686
Kernal:	 2.6.15-1.2054_FC5
gij:     version 4.1.0 20060304 (Red Hat 4.1.0-3)
Azureus: 2.4.0.2     (downloaded from bittorrent site and then self updated)
 and
Azureus: 2.3.0.7_CVS (from the gnome extras site 
http://fedoraproject.org/extras/5/i386/repodata/repoview/azureus-0-2.4.0.0-0.20060209cvs_1.fc5.html)

Logs from the time when the slowed-to-stop is happening show ( Azureus 2.3.0.7_CVS )
[5:17:46.679] {stderr} DEBUG::Sun Apr 02 17:17:46 GMT+12:00
2006::org.gudy.azureus2.core3.peer.util.PeerIdentityManager::removeIdentity::-1:
[5:17:46.681] {stderr}   id not present: id=2D5554313530302DB5813C69DC67184B9A3BD0F1
[5:17:46.682] {stderr}    
PEPeerTransportProtocol::performClose::-1,PEPeerTransportProtocol::closeConnectionInternally::-1,PEPeerTransportProtocol$2::exceptionThrown::-1,NetworkConnectionImpl::notifyOfException::-1,SinglePeerUploader::doProcessing::-1,WriteController::doNormalPriorityWrite::-1,WriteController::writeProcessorLoop::-1,WriteController::access$1::-1,WriteController$2::runSupport::-1,AEThread::run::-1
[5:18:01.627] {stderr} DEBUG::Sun Apr 02 17:18:01 GMT+12:00
2006::org.gudy.azureus2.core3.peer.util.PeerIdentityManager::removeIdentity::-1:
[5:18:01.628] {stderr}   id not present: id=2D5554313530302DB58188CCA0D0FB0D2DFC3A20
[5:18:01.629] {stderr}    
PEPeerTransportProtocol::performClose::-1,PEPeerTransportProtocol::closeConnectionInternally::-1,PEPeerTransportProtocol$3::exceptionThrown::-1,NetworkConnectionImpl::notifyOfException::-1,MultiPeerUploader::write::-1,MultiPeerUploader::doProcessing::-1,WriteController::doHighPriorityWrite::-1,WriteController::writeProcessorLoop::-1,WriteController::access$1::-1,WriteController$2::runSupport::-1,AEThread::run::-1
Comment 2 Anthony Green 2006-04-02 11:08:34 EDT
I suspect that this is due to one or more problems in GNU Classpath's NIO
implementation.  It will take some time to figure out.  Any additional logs or
clues would be helpful.
Comment 3 Andy Burns 2006-04-02 12:11:54 EDT
(In reply to comment #2)

> It will take some time to figure out.

yes, any notion of "repeatable" when communicating to a swarm on the internet
goes out of the window, would it be worth seeding a test torrent on an intranet
to eliminate some variables?

> Any additional logs or clues would be helpful.

I suppose of the console logging to file was functioning it might make
inspection after the event easier.
Comment 4 Anthony Green 2006-04-02 12:37:27 EDT
(In reply to comment #3)
> (In reply to comment #2)
> 
> > It will take some time to figure out.
> 
> yes, any notion of "repeatable" when communicating to a swarm on the internet
> goes out of the window, would it be worth seeding a test torrent on an intranet
> to eliminate some variables?

I wonder if this would be even better:  http://home.gna.org/jockey/
 
> > Any additional logs or clues would be helpful.
> 
> I suppose of the console logging to file was functioning it might make
> inspection after the event easier.

Could you please describe this bug in a separate bug report?

Thanks!



Comment 5 Andy Burns 2006-04-02 18:29:28 EDT
(In reply to comment #4)

> I wonder if this would be even better:  http://home.gna.org/jockey/

x86 only :-(
  
> Could you please describe this bug in a separate bug report?

Actually I had the logging parameters wrong, but after correcting that it turns
out there is a worse bug with logging

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187698

Comment 6 Andy Burns 2006-04-03 08:27:35 EDT
Just upgraded to azureus.x86_64 2.4.0.3-0.20060328cvs_2.fc5 

I haven't tried to download anything new yet, but merely by starting azureus I
am immediately seeding the FC5 DVD ISOs constantly at the full 20Kbps I've
throttled too, which would have been rare before ...

still seeing the same type of errors to console though

[12:31:21.648] {stderr} DEBUG::Mon Apr 03 12:31:21 GMT
2006::com.aelitis.azureus.core.networkmanager.VirtualChannelSelector::select::-1:
[12:31:21.649] {stderr}   Caught exception on selector.select() op: 3
[12:31:21.650] {stderr}    
ReadController::readSelectorLoop::-1,ReadController::access$0::-1,ReadController$1::runSupport::-1,AEThread::run::-1
[12:31:21.718] {stderr} java.lang.ArrayIndexOutOfBoundsException: 3
[12:31:21.719] {stderr}    at gnu.java.nio.SelectorImpl.getFDsAsArray (libgcj.so.7)
[12:31:21.720] {stderr}    at gnu.java.nio.SelectorImpl.select (libgcj.so.7)
[12:31:21.720] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.VirtualChannelSelectorImpl.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}    at
com.aelitis.azureus.core.networkmanager.VirtualChannelSelector.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController.readSelectorLoop
(Azureus2.jar.so)
[12:31:21.722] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController.access$0
(Azureus2.jar.so)
[12:31:21.722] {stderr}    at
com.aelitis.azureus.core.networkmanager.impl.ReadController$1.runSupport
(Azureus2.jar.so)
[12:31:21.723] {stderr}    at org.gudy.azureus2.core3.util.AEThread.run
(Azureus2.jar.so)


[12:31:28.991] {stderr} DEBUG::Mon Apr 03 12:31:28 GMT
2006::org.gudy.azureus2.core3.peer.util.PeerIdentityManager::removeIdentity::-1:
[12:31:28.992] {stderr}   id not present:
id=2D5554313430302D928124D755F4865965E2C4F1
[12:31:28.993] {stderr}    
PEPeerTransportProtocol::performClose::-1,PEPeerTransportProtocol::closeConnection::-1,PEPeerControlImpl::closeAndRemovePeer::-1,PEPeerControlImpl::checkSeeds::-1,PEPeerControlImpl::schedule::-1,PeerControlSchedulerImpl$instanceWrapper::schedule::-1,PeerControlSchedulerImpl::schedule::-1,PeerControlSchedulerImpl$1::runSupport::-1,AEThread::run::-1


[12:31:34.410] {stderr} DEBUG::Mon Apr 03 12:31:34 GMT
2006::org.gudy.azureus2.core3.peer.util.PeerIdentityManager::removeIdentity::-1:
[12:31:34.411] {stderr}   id not present:
id=6578626301014C4F52445B0CA7F46DDF36AB1C6B
[12:31:34.412] {stderr}    
PEPeerTransportProtocol::performClose::-1,PEPeerTransportProtocol::closeConnection::-1,PEPeerControlImpl::closeAndRemovePeer::-1,PEPeerControlImpl::checkSeeds::-1,PEPeerControlImpl::schedule::-1,PeerControlSchedulerImpl$instanceWrapper::schedule::-1,PeerControlSchedulerImpl::schedule::-1,PeerControlSchedulerImpl$1::runSupport::-1,AEThread::run::-1
Comment 7 Anthony Green 2006-04-03 08:57:14 EDT
I've added a reference to the upstream GNU Classpath bug (#23682).
Comment 8 Andy Burns 2006-06-23 17:02:31 EDT
I haven't used azureus on FC5 for a while, but have been downloading the FC6T1
DVD iso with it over last couple of days, this is with FC5 updates/extras as of
2006-06-22, it has maintained throughput, without requiring exit/restart,
subject to the limits of packet shaping my ISP now applies :-(

I think this bug can be considered resolved as far as I'm concerned ...

Comment 9 Anthony Green 2006-07-09 10:00:41 EDT
Well, here's one fix that eliminates numerous timeouts that show up like this in
the log files...

05:33:36.613 0 nwman   incoming crypto handshake failure: Protocol decode
aborted: timed out after 60sec: 0 bytes read

We package bouncycastle separately from azureus.  We also use the upstream bc
sources instead of those bundled with azureus.  bc 1.31 was the latest version
available at the time of FC5.  The azureus team, however, had discovered a bug
in bc 1.31 and fixed it in their bundled version.  If I fix that same bug in the
FC5 bc (which we are bundling with java-1.4.2-gcj-compat) then these frequent
timeouts go away.

For FC6 we've pulled bc out of java-1.4.2-gcj-compat and into its own package. 
 We're using 1.33 there, and this bug is already fixed.

I'll attach the patch to this bugzilla entry, and ask fitzsim to apply to
java-1.4.2-gcj-compat for FC5.
Comment 10 Anthony Green 2006-07-09 10:02:48 EDT
Created attachment 132130 [details]
Patch

This patch to java-1.4.2-gcj-compat fixes timeout problems in azureus.
Comment 11 Andy Burns 2006-07-09 10:22:46 EDT
I'd put those down to connections with peers not supporting encryption

I have an FC6/rawhide box, but don't have azureus on it yet, though I do notice
that the azureus in FE6 is an older cvs snapshot that FE5
Comment 12 Anthony Green 2006-07-09 10:41:21 EDT
(In reply to comment #11)
> I'd put those down to connections with peers not supporting encryption

I used to get those timeouts every 5 to 10 seconds.  But since I made this
change I've only received one in the past 30 minutes or so.  I assume this is
because the crypto being used in the handshake was broken in our build.

> I have an FC6/rawhide box, but don't have azureus on it yet, though I do notice
> that the azureus in FE6 is an older cvs snapshot that FE5

I have a new FE6 build ready.  I was able to remove a number of the SWT patches,
since now we have SWT 3.2.

Grab:
http://people.redhat.com/~green/FE/devel/azureus-2.4.0.3-0.20060702cvs_2.src.rpm

The reason it's not in extras yet is because it's waiting on the following two
packages to show up in Core:

http://people.redhat.com/fitzsim/bouncycastle-1.33-1.src.rpm
http://people.redhat.com/fitzsim/java-1.4.2-gcj-compat-1.4.2.0-40jpp_88rh.src.rpm

One gotcha in this package is that optimization is turned off because of a bug
in GCC. 
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
Comment 13 Dominik 'Rathann' Mierzejewski 2006-08-16 09:54:14 EDT
It happens to me with azureus-2.4.0.3-0.20060604cvs_1.fc5. Any chance of fixing
this in FC5 soon?
Comment 14 Kyrre Ness Sjøbæk 2006-08-22 17:13:35 EDT
I'm also seeing it, version
azureus-2.4.0.3-0.20060604cvs_1.fc5
Comment 15 Kyrre Ness Sjøbæk 2006-08-23 11:13:15 EDT
After installing Sun JRE using the instructions at fedorafaq, the problem went
away (at least all the error messages at startup).

Ao it really looks like a GCJ/classpath bug.
Comment 16 Anthony Green 2006-09-11 22:11:59 EDT
*** Bug 206078 has been marked as a duplicate of this bug. ***
Comment 17 Dick Thomas 2007-03-22 12:35:23 EDT
I also have the problem of them slowing down to nothing after a few min/hours
while if i use another client (e.g ktorrent) they run fine
What kind of bug reports would be required to help on this matter?
Comment 18 Jamey Fletcher 2007-03-29 19:26:17 EDT
I'm seeing this behavior as well - using a just installed and fully-updated FC6
x86_64 install.

Installed packages are:
azureus-2.5.0.0-11.fc6
bouncycastle-1.34-2.fc6

And java -version is:
gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51)

I would go for the JPackage installation of Sun's java, but it's up to Release
11, and JPackage only has release 10 available.
Comment 19 Anthony Green 2007-11-11 16:28:13 EST
Fedora 8 ships with IcedTea which, while not yet perfect, doesn't have any of
these performance issues.  I'm going to close this bug as WONTFIX since the
issue is really with gcj, and I don't expect anyone will put the effort into
addressing the underlying gcj/classpath issues now that we have IcedTea.

Note You need to log in before you can comment on or make changes to this bug.