Bug 187103

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

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.

(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.

(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!

(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

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

I've added a reference to the upstream GNU Classpath bug (#23682).

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 ...

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.

Created attachment 132130 [details]
Patch

This patch to java-1.4.2-gcj-compat fixes timeout problems in azureus.

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

(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

It happens to me with azureus-2.4.0.3-0.20060604cvs_1.fc5. Any chance of fixing
this in FC5 soon?

I'm also seeing it, version
azureus-2.4.0.3-0.20060604cvs_1.fc5

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.

*** Bug 206078 has been marked as a duplicate of this bug. ***

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?

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.

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.