Azureus + 7-STABLE == Slow download + No Upload

[Marc G. Fournier]

> The reason that we've persisted with doing patchsets for Java is so that 
> everybody can get at the source and investigate/fix things which are 
> important to them.  I've persistently argued against switching solely to 
> binary releases, when that has come up, for just this reason.

First, a note ... I think the Java group is doing a fantastic job, 
considering all of the hurdle that you guys had to jump through at the 
start of this with NDA (I believe?) and such ... please do not take *any* 
of what I have (or will) say as anything but an attempt to further 
improve, as they aren't meant as anything but ...

> So, if you can't find someone on the porting team who is both interested
> and has time to investigate it right now then there are a number of things
> you can do yourrselves to start the investigation.

In this case, I'm curious as to why nobody is taking this as an 
opportunity ... Azureus is a huge piece of software, that tends to make 
extensive use of threading (from what I can tell), and since at least 6.x, 
has had problem reports when trying to do 'two things at once' ... if this 
is a coding bug with Azureus itself, fine, but if this is a bug with 
FreeBSD (ie. our threading + java) that Azureus highlights to the extreme, 
then if we can get Azureus fixed, that would trickle down to other less 
'intense' java applications, and, possible even non-java ones ...

*But* ... after installing deluge (python), which I'm getting massive 
transfer rates (such that I'd never seen with Azureus even at its best) 
even with 20+ torrents on the go, I don't see it as being a FreeBSD 
threading issue, except for how that interacts with Java+Azureus ...

Now, it could be like with Wine, where Azureus was programmed with 'linux 
in mind', so that someone is missing / broken in FreeBSD/java in relation 
... but even knowing *that* would at least make it easier for ppl posting 
about such issues ...

> . Look through the list archives into what people have found out about
>  problems with Azureus before.  This isn't the first time this has come
>  up.

I've done that, and you are right, it isn't the firs time ... the bulk of 
the reports have revolved around 6.x, where you need to add an entry to 
/etc/libmap.conf to map pthread -> thr ... with that, Azureus on 6.x works 
fine, but with 7.x, thr is the default library, and I've checked jdk15 
using ldd to make sure that that is what is being used ...

The only other issue I've found relates to IPv6, but I don't have that 
built into my kernel, and, just in case, I did add the flag that was 
suggested to force IPv4 ...

The other email's that I've seen on the subject generally went along the 
lines of "I gave up on Azureus+Java and moved to something else to fix the 
problem" ...


> . Look at what the kernel threads are doing periodically with ps(1).

What should one be looking at here?  I have no problems with doing the 
'leg work' on this, just need to know what I need to be looking for ...

> . Dump the Java threads periodically.

Huh?

> . Run Azureus under ktrace and look at what syscalls are being made.
>  There is going to be a lot of output from ktrace I expect, so its
>  going to take some time to sort through.

I have the disk space, but insufficicent knowledge to know what I'm 
looking for from the output ...

> . Run this on 6.x and 7.x and try the different threading libraries.

6.x runs fine with the pthread->thr map in /etc/libmap.conf ... I've tried 
it on 7.x with both diablo (uses pthreads, I believe) and jdk15 (with thr) 
.. same results ...

> . Run it on Linux and compare what it does if you're interested.

Not an option ... I don't have a Linux box to run it on ...

> . Run it under different JDKs to see if that makes any difference.

Tried both diablo and jdk15 ... haven't tried the linux jdk though, will 
look at installing that tonight ...