thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reiss <dre...@facebook.com>
Subject Re: multi thread requests handling
Date Thu, 23 Apr 2009 17:29:38 GMT
> 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.

You have to read the entire request before handing off to the processor
code.  This is because the processor will attempt to deserialize the
entire request.  If it is deserializing from a buffer, it will reach the
end and throw an exception, wasting valuable CPU time reading a request
that is not complete.  If it is deserializing directly from the socket
(or a TBufferedTransport on the socket), it will block until the rest of
the message arrives, which makes that thread useless.  Does this make
sense?

--David

Mime
View raw message