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 [email protected] 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 > <[email protected]>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
