thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Simpkins <simpk...@facebook.com>
Subject Re: Store client data in server thread?
Date Thu, 06 May 2010 04:04:48 GMT
I've been working on a patch to support this functionality by adding
processor factories.  It allows you to create a new handler object for
each client connection.  Your handler class can then store whatever
connection-specific state it wants.

When a new connection arrives, the server code calls the processor
factory and passes in some context about the connection.  The
processor factory can always return a pointer to the same processor
object, to be compatible with the current thrift behavior.  However,
you can also have it create a new processor+handler for each
connection, to achieve the one-handler-per-connection behavior.

One downside is that it requires some effort to update existing
services to use this model if they've already been written to store
global state in the handler object.

So far my code is only for C++.  It will probably be several more
weeks at least before I'll have a patch ready to submit to the JIRA.
(I think my change depends on some other C++ patches we've made at
Facebook that still need to get pushed out to the JIRA first.)

-- 
Adam Simpkins
simpkins@facebook.com

On Wed, May 05, 2010 at 08:33:55PM -0700, Bryan Duxbury wrote:
> People have asked for this in the past, and unfortunately we don't currently
> offer it. What kind of interface do think we should support? I'd love to see
> a patch for this (hint hint).
> 
> As a fallback, you could always make a custom Server implementation based
> off of one of the existing servers that doesn't use a thread pool in this
> fashion, which would let you use ThreadLocals.
> 
> -Bryan
> 
> On Wed, May 5, 2010 at 7:39 PM, Kenny MacDermid
> <kenny.macdermid@gmail.com>wrote:
> 
> > Is there any recommended way to store information about the connected
> > client in Thrift?
> >
> > I was looking to store the client information the way Cassandra does, using
> > ThreadLocal<> stores in the Server, but it appears this doesn't work.
> > Threads will be reused by the thread pool, so client information could be
> > reused.
> >
> > I'd like a way for clients to login() and not have to send a cookie back
> > with all future requests. Is this possible?
> >
> > Thanks,
> >
> > Kenny

Mime
View raw message