You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Ryan King <ry...@twitter.com> on 2010/11/12 23:50:35 UTC
TFastFramedTransport
We're trying to test TFastFramedTransport with a project, but we're
either misunderstanding something.
We're trying to use it with THsHaServer, but ran into a few problems:
* THsHaServer requrires a TFramedTransport.Factory, but
TFastFramedTransport.Factory isn't a subclass of that. Seems wrong,
no?
* also, since TFastFramedTransport.Factory doesn't memoize the
transport, we create a new object for each request and its therefore
at least as resource intensive as the alternative
So yeah, I hope we're just missing something. Otherwise this
combination appears to be broken.
-ryan
Re: TFastFramedTransport
Posted by Bryan Duxbury <br...@rapleaf.com>.
https://issues.apache.org/jira/browse/THRIFT-963
Open to patches :)
On Mon, Nov 15, 2010 at 10:17 AM, Ryan King <ry...@twitter.com> wrote:
> On Sat, Nov 13, 2010 at 2:33 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> > No, you have it right, Johnathan. It's just that the way that
> > Nonblocking/HsHa server work, they don't really use the supplied
> transport
> > for anything except the last little bit of the pipeline prior to method
> > invocation. Those two servers in particular are *implicitly*
> > framed-transport-only.
>
> Ok, this makes a bit more sense. Would it make sense to have the THsHA
> server reuse its buffers then? I think it could be a serious win for
> many workloads.
>
> -ryan
>
Re: TFastFramedTransport
Posted by Ryan King <ry...@twitter.com>.
On Sat, Nov 13, 2010 at 2:33 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> No, you have it right, Johnathan. It's just that the way that
> Nonblocking/HsHa server work, they don't really use the supplied transport
> for anything except the last little bit of the pipeline prior to method
> invocation. Those two servers in particular are *implicitly*
> framed-transport-only.
Ok, this makes a bit more sense. Would it make sense to have the THsHA
server reuse its buffers then? I think it could be a serious win for
many workloads.
-ryan
Re: TFastFramedTransport
Posted by Bryan Duxbury <br...@rapleaf.com>.
No, you have it right, Johnathan. It's just that the way that
Nonblocking/HsHa server work, they don't really use the supplied transport
for anything except the last little bit of the pipeline prior to method
invocation. Those two servers in particular are *implicitly*
framed-transport-only.
On Sat, Nov 13, 2010 at 9:11 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Fri, Nov 12, 2010 at 5:56 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> > THsHaServer neither supports nor would benefit from TFastFramedTransport.
> In
> > fact, Both nonblocking and HsHa servers are pretty good already when it
> > comes to interacting with the server-side per-request transport, so it's
> > unnecessary. (There is an opportunity to make those servers reuse their
> > buffers, but I haven't had a chance to make those changes yet.)
>
> I thought reusing its buffers was the whole point of
> TFastFramedTransport. Are there other differences from TFramedT?
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>
Re: TFastFramedTransport
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Nov 12, 2010 at 5:56 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> THsHaServer neither supports nor would benefit from TFastFramedTransport. In
> fact, Both nonblocking and HsHa servers are pretty good already when it
> comes to interacting with the server-side per-request transport, so it's
> unnecessary. (There is an opportunity to make those servers reuse their
> buffers, but I haven't had a chance to make those changes yet.)
I thought reusing its buffers was the whole point of
TFastFramedTransport. Are there other differences from TFramedT?
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: TFastFramedTransport
Posted by Bryan Duxbury <br...@rapleaf.com>.
THsHaServer neither supports nor would benefit from TFastFramedTransport. In
fact, Both nonblocking and HsHa servers are pretty good already when it
comes to interacting with the server-side per-request transport, so it's
unnecessary. (There is an opportunity to make those servers reuse their
buffers, but I haven't had a chance to make those changes yet.)
On Fri, Nov 12, 2010 at 2:50 PM, Ryan King <ry...@twitter.com> wrote:
> We're trying to test TFastFramedTransport with a project, but we're
> either misunderstanding something.
>
> We're trying to use it with THsHaServer, but ran into a few problems:
>
> * THsHaServer requrires a TFramedTransport.Factory, but
> TFastFramedTransport.Factory isn't a subclass of that. Seems wrong,
> no?
> * also, since TFastFramedTransport.Factory doesn't memoize the
> transport, we create a new object for each request and its therefore
> at least as resource intensive as the alternative
>
> So yeah, I hope we're just missing something. Otherwise this
> combination appears to be broken.
>
> -ryan
>