Your message dated Thu, 13 Aug 2009 10:57:13 -0400 with message-id <1250175433.12712.10.ca...@desktop> and subject line azureus: Very high CPU load has caused the Debian Bug report #466236, regarding azureus: Very high CPU load to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 466236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466236 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: azureus Version: 3.0.4.2-1 Severity: important The download directory of Azureus is, in my case, on a fat32 partition. When a download begins, azureus spends a very long time (5 - 20 minutes) "allocating" space in the download directory. The time required seems to go up faster than linearly with the size of the file to be downloaded. While azureus is allocating, the load average of the machine goes to ridiculous levels (at least 10). Everything (mouse, keyboard, the onscreen clock) freezes. Sometimes I cannot even go to a VC with control-alt-F2; sometimes I can, but I have to wait for a while until the system reacts to the keyboard command. There are no error messages. After the waiting period is over, the download begins. The load average remains fairly high (1 or so) and according to "top", java consumes about 25% CPU; this remains so until the download is over. I then discovered the option Tools -> Options -> Files -> "Enable incremental file creation." With this, a download does not start with an "allocating" phase. The download begins at once. At least, azureus says so; but it is not true. By doing ls -al on the download directory I can see that the complete file size is still being allocated in advance (with the same effects as before: allocation proceeds very slowly, ridiculously high load average, freeze of all processes including the download itself, which remains at zero bytes until the allocation is finally finished). This penomenon is fairly recent, but I could not say with which version of azureus it started. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages azureus depends on: pn java-gcj-compat | java-virtua <none> (no description available) ii libcommons-cli-java 1.1-1 API for working with the command l ii liblog4j1.2-java 1.2.15-2 Logging library for java ii libseda-java 3.0-3 the Staged Event-Driven Architectu ii libswt-gtk-3.3-java 3.3.1-3 Standard Widget Toolkit for GTK Ja ii sun-java6-jre [java2-runtime] 6-04-2 Sun Java(TM) Runtime Environment ( azureus recommends no packages. -- debconf-show failed
--- End Message ---
--- Begin Message ---It was fixed around version 4 according to the changelog. It's now 4.2.0.4-1 in unstable. -- Best regards, Adrian Perez <adrianperez....@gmail.com>signature.asc
Description: This is a digitally signed message part
--- End Message ---
_______________________________________________ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers