thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenny MacDermid <>
Subject Re: Store client data in server thread?
Date Fri, 07 May 2010 04:06:05 GMT
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?



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
> <>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

View raw message