#3836 closed Enhancement (fixed)
libevent 2 support
Reported by: | charles | Owned by: | jordan |
---|---|---|---|
Priority: | Normal | Milestone: | 2.20 |
Component: | Transmission | Version: | 2.13 |
Severity: | Normal | Keywords: | |
Cc: |
Description
libevent2 has gone stable, so we should convert our API from libevent 1.4.x to libevent2
Attachments (1)
Change History (32)
Changed 12 years ago by charles
comment:1 Changed 12 years ago by charles
ticket #2253 has been superceded by this ticket.
comment:2 Changed 12 years ago by charles
added to libT in r11548
comment:3 Changed 12 years ago by charles
r11553: silence a pair of 'unused variable' compiler warnings
comment:4 in reply to: ↑ description Changed 12 years ago by gunzip
Replying to charles:
libevent2 has gone stable, so we should convert our API from libevent 1.4.x to libevent2 preliminary patch of libevent2 support. requires >= 2.0.10
where does one get libevent2 2.0.10 in linux?
the debian "experimental" repos has version 2.0.3-alpha-1, and the libevent homepage at http://www.monkey.org/~provos/libevent/ has up to version libevent-2.0.9-rc
i tried compiling with libevent-dev 2.0.3-alpha-1 but got error during ./configure "requires >= 2.0.10"
comment:5 Changed 12 years ago by Rolcol
gunzip, you can get libevent 2.0.10 from here: http://sourceforge.net/projects/levent/files/libevent/libevent-2.0/
You'll need to compile it yourself, unless you can find a Debian package for it.
comment:6 follow-up: ↓ 8 Changed 12 years ago by gunzip
Thanks Rolcol, i didn't realize libevent had an alternate homepage. Anyway i'm going to give it a go and see what shakes out.
UPDATE:
Everything compiled fine now with libevent 2.0.10. One minor hiccup is i had to use
./configure --prefix=/usr/
otherwise the libevent* files were installed under /usr/local/ and the transmission-daemon couldn't find them.
Linux Debian, transmission-daemon 2.13+ (11556)
comment:7 Changed 12 years ago by livings124
- Milestone changed from Sometime to 2.20
comment:8 in reply to: ↑ 6 Changed 12 years ago by charles
Replying to gunzip:
Thanks Rolcol, i didn't realize libevent had an alternate homepage. Anyway i'm going to give it a go and see what shakes out.
UPDATE:
Everything compiled fine now with libevent 2.0.10. One minor hiccup is i had to use
./configure --prefix=/usr/
otherwise the libevent* files were installed under /usr/local/ and the transmission-daemon couldn't find them.
This is nonstandard, but FWIW I did it like this when building libevent:
1) ./configure --prefix=$HOME/opt/libevent
2) export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$HOME/opt/libevent/lib/pkgconfig"
Rationale: this way it doesn't pollute the installed packages in /usr, and also is in a place where I can delete it easily and start from scratch when libevent 2.0.11 comes out. Note: I'm not sure if this approach would survive a "make install" step, but I never do that with transmission...
comment:9 Changed 12 years ago by Rolcol
I basically did the same as Charles. My prefix was just Transmission/libevent2.
Charles, Transmission statically linked against libevent2 for me. I ran into no issues with 'make install'.
comment:10 Changed 12 years ago by gunzip
i think i found a simple solution that allows me to keep all the lib/libevent* files in /usr/local/ and avoid the co-mingling with the debian package files in /usr/lib/
1) i uninstalled both libevent2 and transmission (make uninstall, make distclean) to start with a clean slate
2) compiled libevent2 and transmission normally (./configure, make, make install)
3) ran command ldconfig , which in debian automatically searches for and updates the shared libraries, which by default includes the path /usr/local/lib/
4) now the transmission-daemon starts up with no errors
BTW, should this libevent2 upgrade give some kind of performance boost? just curious what it means to us average users.
comment:11 Changed 12 years ago by starmoon
same question as gunzip. why we must use libevent2?
met problem with rhel5.5 (centos 5.5). the last stock update libevent is 1.4.13-1.
comment:12 Changed 12 years ago by gunzip
since this upgrade to libevent2 transmission-remote-cli.py, which always had worked flawlessly with transmission-daemon, repeatedly crashes to the point it is barely usable anymore. errors starts off as
"Cannot not parse response: {"arguments":{"torrents" ..."
not sure but it might be related to this new ticket https://trac.transmissionbt.com/ticket/3843
comment:13 Changed 12 years ago by charles
gunzip: confirmed.
Ticket #3843 has been absorbed by this ticket.
comment:14 Changed 12 years ago by charles
comment:15 Changed 12 years ago by gunzip
cheers, r11564 has solved the transmission-remote-cli.py crashing problem.
comment:16 Changed 12 years ago by starmoon
transmission-remote-gui/dotnet are happy again.
btw: remoto to daemon connection speed are faster than before, and transmission-daemon itself cpu ultilize seems dropped a lot. (300+torrents, 80% dropped to 50%)
comment:17 Changed 12 years ago by charles
comment:18 Changed 12 years ago by charles
r11590 -- use libevent2 headers in the daemon directory too.
comment:19 Changed 12 years ago by charles
r11591 -- don't #include evhttp.h in the gtk/ client
comment:20 Changed 12 years ago by charles
r11594. - get the non-inotify chunks of code working with libevent2
comment:21 Changed 12 years ago by jch
comment:22 Changed 12 years ago by charles
comment:23 Changed 12 years ago by reardon
Comment: in my experience the switch to libevent2 is rough at the moment. Building from svn (circa 11616): doesn't scale well. At small number of torrents, seems to have better latency. But at large number (~900), latency becomes quite large, much worse than previous libevent. I have done no detailed investigation but just passing along anecdotal usage. The effects are the worst with transgui and transmission-remote-dotnet, not as bad with webclient.
comment:24 Changed 12 years ago by jordan
I'm not sure how to interpret give the previous report. Your choice of which remote control to use shouldn't affect latency.
comment:25 Changed 12 years ago by reardon
Here was the scenario: 800 torrents. When ~20 torrents were active (at approx 4MB/s total throughput), the rpc interface slowed to a crawl, with the latency increased 10-100x versus normal. I tried different clients just to make sure it was not client-specific but rather rpc-specific.
With few active torrents, latency is normal. I don't know what kind of load testing you have done but recommend that you do so so with both >500 torrents loaded and >20 active.
The switch to libevent2 is a significant one and doesn't have a lot of real-world validation from other implementers. I'm sure you've thought long and hard about the switch before committing and likely recognize that it needs such scale testing.
comment:26 Changed 12 years ago by jch
Just to report that Transmission now builds fine against the libevent2 in Debian-experimental.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607984#24
--jch
comment:27 Changed 12 years ago by jordan
- Resolution set to fixed
- Status changed from new to closed
Well, libevent2 is fully implemented and we're just about ready for the 2.20 beta.
If any issues arise, we can address them in another ticket.
comment:28 Changed 12 years ago by jordan
- Resolution fixed deleted
- Status changed from closed to reopened
comment:29 Changed 12 years ago by jordan
- Owner set to jordan
- Status changed from reopened to new
comment:30 Changed 12 years ago by jordan
- Resolution set to fixed
- Status changed from new to closed
comment:31 Changed 12 years ago by jordan
jordan * r11803 libtransmission/peer-io.c:
(trunk libT) #3836 "libevent 2 support" -- fix minor memory leak.
tr_peerIoReconnect() was calling event_del() rather than event_free() on its io.event_read and io.event_write fields, causing those fields to be leaked. This behavior is new with libevent 2 support and doesn't affect transmission 2.1x or older.
very preliminary patch of libevent2 support. requires >= 2.0.10