Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

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

libevent2.patch (85.9 KB) - added by charles 10 years ago.
very preliminary patch of libevent2 support. requires >= 2.0.10

Download all attachments as: .zip

Change History (32)

Changed 10 years ago by charles

very preliminary patch of libevent2 support. requires >= 2.0.10

comment:1 Changed 10 years ago by charles

ticket #2253 has been superceded by this ticket.

comment:2 Changed 10 years ago by charles

added to libT in r11548

comment:3 Changed 10 years ago by charles

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

comment:4 in reply to: ↑ description Changed 10 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 10 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: Changed 10 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)

Last edited 10 years ago by gunzip (previous) (diff)

comment:7 Changed 10 years ago by livings124

  • Milestone changed from Sometime to 2.20

comment:8 in reply to: ↑ 6 Changed 10 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...

Last edited 10 years ago by charles (previous) (diff)

comment:9 Changed 10 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'.

Last edited 10 years ago by Rolcol (previous) (diff)

comment:10 Changed 10 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 10 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 10 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 10 years ago by charles

gunzip: confirmed.

Ticket #3843 has been absorbed by this ticket.

comment:14 Changed 10 years ago by 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

comment:15 Changed 10 years ago by gunzip

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

comment:16 Changed 10 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 10 years ago by 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.

comment:18 Changed 10 years ago by charles

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

comment:19 Changed 10 years ago by charles

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

comment:20 Changed 10 years ago by charles

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

comment:22 Changed 10 years ago by 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

comment:23 Changed 10 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.

Last edited 10 years ago by reardon (previous) (diff)

comment:24 Changed 10 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 10 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 10 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 10 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 10 years ago by jordan

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:29 Changed 10 years ago by jordan

  • Owner set to jordan
  • Status changed from reopened to new

comment:30 Changed 10 years ago by jordan

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

comment:31 Changed 10 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.

Note: See TracTickets for help on using tickets.