thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Debacker <deback...@gmail.com>
Subject multi thread requests handling
Date Thu, 23 Apr 2009 11:47:55 GMT
Hi,

By reading the Java library, I noticed that each connection (transport) gets
its own thread (in the thread-pool version), so a given thread will process
requests of a single connection. In the single thread version, you can only
have a single connection concurrently. Why not accepting connection as they
arrive, initiate a read on all of them, put them is something like an epoll
(Linux world), and the pool of k threads would take care of the next request
of the next k connection which responded. When a thread has done with a
request, it can put it back in the epoll, and pick up another one. That's
based on event-based servers such as Nginx or Cherokee.

Could you tell me why the current design has been selected? I think that the
best way to use the current server is by creating a connection, making a
call or two, then disconnect. But socket creation takes time, that's why it
would be nicer to keep some connections open, and reuse them when needed
(think about connection pool of database, but instead of a database, you get
thrift).

I have noticed your non blocking server based on
http://java.sun.com/javase/6/docs/api/java/nio/channels/spi/SelectorProvider.html,
but you use the framed protocol to read the whole packet completely before
calling the implementation. But this is not needed, as I said in the first
paragraph, we could just read the first chunk of bytes (i.e. 4096) of each
connection. This would required one read buffer per connection, but it is
not a problem since the objective would be to reuse the connections.

Thanks,
Laurent Debacker.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message