libevent 2 support

[charles]

libevent2 has gone stable, so we should convert our API from libevent 1.4.x to libevent2

[charles]

very preliminary patch of libevent2 support. requires >= 2.0.10

[charles]

ticket #2253 has been superceded by this ticket.

[charles]

added to libT in r11548

[charles]

r11553: silence a pair of 'unused variable' compiler warnings

[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"

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

[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)

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

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

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

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

[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

[charles]

gunzip: confirmed.

Ticket #3843 has been absorbed by this ticket.

[charles]

r11564 libtransmission/bencode.c: (trunk libT) #3836 "libevent2 support" -- optimize serialization of json strings for libevent2's new evbuffer API. This also fixes #3843

[gunzip]

cheers, r11564 has solved the transmission-remote-cli.py crashing problem.

[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%)

[charles]

r11588 libtransmission/ (17 files): (trunk libT) #3836 "libevent2 support" -- finish moving to the libevent2 API mode. don't include the backwards-compatable API headers.

[charles]

r11590 -- use libevent2 headers in the daemon directory too.

[charles]

r11591 -- don't #include evhttp.h in the gtk/ client

[charles]

r11594. - get the non-inotify chunks of code working with libevent2

[jch]

​http://bugs.debian.org/607984

[charles]

r11616 qt/ (qtr.pro session.cc session.h): (trunk qt) #3836 "libevent2 support" -- add a mechanism to make it easier to build the Qt client with custom installs of libevent2

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

[jordan]

I'm not sure how to interpret give the previous report. Your choice of which remote control to use shouldn't affect latency.

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

[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

[jordan]

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.

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