thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: Store client data in server thread?
Date Fri, 07 May 2010 14:38:21 GMT
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
<kenny.macdermid@gmail.com>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
> > <kenny.macdermid@gmail.com>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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message