I think the solution for me is to replace the ExecutorService in the TThreadPoolServer with a ThreadPoolExecutor that overrides the afterExecute() method. Then the client data can be stored in ThreadLocal<>s on the Processor.Iface, and cleaned up in afterExecute().
The ThreadPoolExecutor is created when you have access to the Iface so can call any cleanup on it. The ExecutorService in the TThreadPoolServer is private, so the only ways I have to replace it are reflection, or copying the whole class. I'm not a big fan of either. Adding another parameter to the constructors seems wrong too, as it would almost double the 9 already there. Can anyone suggest a better way? Thanks, Kenny On 2010-05-05, at 11:33 PM, 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
