Hi Bryan, Can you take a look at the attached patch and tell me if this is along the lines of what you were thinking.
It allows the creation of a TThreadPoolServer with any combination of fields. It could later be refactored to have a TServerBuilder and the TThreadPoolServerBuilder could extend from that. Kenny
On 2010-05-07, at 10:38 AM, Bryan Duxbury wrote: > 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 >> >>
