I certainly don't want you to use reflection to get at the ExecutorService. Adding a constructor is the naive way to do it, but as you say, it makes the number of constructors go a bit out of control. I have previously proposed making a Builder for each of our nontrivial servers, which would allow you to specify what you'd like via separate methods instead of via the constructor. I'd gladly accept a patch that implemented the Builder behavior in order to provide the functionality you need.
-Bryan On Thu, May 6, 2010 at 9:06 PM, Kenny MacDermid <[email protected]>wrote: > 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 > >
