Opened 14 years ago

Closed 14 years ago

#1440 closed Bug (duplicate)

webUI disconnecting clients every 1-2 minutes

Reported by: dzimi Owned by: Gimp
Priority: Highest Milestone: None Set
Component: Web Client Version: 1.34
Severity: Critical Keywords:
Cc:

Description

Hello,

I am using transmissionbt on high load system, where are running many of transmission-deamon processes. From time to time webUI disconnecting clients from webUI (every 1-2 minutes). The same problem exist when clients use Transmission BitTorrent? Controller. I don't know - is problem is with rpc server or webUI build in server. When I kill the process and run it again - problem start again. I saw, when webUI die, transfers still running and downloading data.

CPU usage ~ 30%. 70 running transmission-deamon process on it. Machine is Core2Duo 2,4Ghz, 4GB RAM, fast SAS disks.

tested with 1.34 and 1.40b1 and 1.34+ (7071). Linux 2.4.24 kernel, debian lenny.

Change History (5)

comment:1 Changed 14 years ago by dzimi

forgot add. Problem is when you refresh webUI page ("Connection Failed Could not connect to the server. You may need to reload the page to reconnect.") or when you hit pause all torrent (i had loaded active 19 torrents - I may give you direct link to this problem (krzysztof.taraszkaAT_gnuhosting.net)

comment:2 Changed 14 years ago by dzimi

log look like that:

Transmission 1.34 (6778) started Searching for web interface file "/home/749/.local/share/transmission/web/javascript/transmission.js" Searching for web interface file "/usr/local/sharetransmission/web/javascript/transmission.js" Serving the web interface files from "/usr/local/sharetransmission/web" transmission-daemon: requiring authentication Port Forwarding: Opened port 14660 to listen for incoming peer connections debian-LennyBeta2-i386-CD-3.iso: Queued for verification debian-LennyBeta2-i386-CD-3.iso: Verifying torrent debian-40r4a-amd64-DVD-1.iso: Queued for verification Loaded 4 torrents debian-LennyBeta2-i386-CD-1.iso: Got 32 peers from tracker debian-40r4a-amd64-DVD-1.iso: Verifying torrent debian-LennyBeta2-i386-CD-3.iso: Got 11 peers from tracker debian-LennyBeta2-i386-CD-3.iso: State changed from "Incomplete" to "Complete" debian-LennyBeta2-i386-CD-3.iso: Got 11 peers from tracker debian-40r4a-amd64-DVD-1.iso: Got 33 peers from tracker debian-40r4a-powerpc-DVD-3.iso: Couldn't read resume file debian-40r4a-powerpc-DVD-3.iso: Queued for verification debian-40r4a-powerpc-DVD-3.iso: Verifying torrent debian-40r4a-powerpc-DVD-3.iso: Got 1 peers from tracker generic i/o errno from errno: No such file or directory generic i/o errno from errno: No such file or directory generic i/o errno from errno: No such file or directory

comment:3 Changed 14 years ago by charles

  • Milestone changed from 1.40 to None Set

When you set the milestones, you're saying one of two things: (1) you are volunteering to fix the problem, or (2) you're giving the Transmission team marching orders.

comment:4 Changed 14 years ago by charles

dzimi: there have been huge changes under the covers between 1.34 and 1.40 in how RPC and the web pages are served: 1.34 used shttpd, and 1.40 uses evhttp, which is a better fit for libtransmission's libevent-based system.

Is there any more information you can provide on how this bug behaves in 1.40? How can I go about reproducing it without running 70 copies of transmission-daemon?

comment:5 Changed 14 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

If I'm understanding dzimi's comments in #transmission correctly, these disconnects are being caused by the libtransmission/libevent thread freezing on disk IO operations.

Marking this ticket as a duplicate of #651. However if I've misunderstood you, please reopen this ticket.

Note: See TracTickets for help on using tickets.