You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Kenny MacDermid <ke...@gmail.com> on 2010/05/06 04:39:09 UTC
Store client data in server thread?
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
Re: Store client data in server thread?
Posted by Kenny MacDermid <ke...@gmail.com>.
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
Re: Store client data in server thread?
Posted by Bryan Duxbury <br...@rapleaf.com>.
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
<ke...@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
> > <ke...@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
>
>
Re: Store client data in server thread?
Posted by Kenny MacDermid <ke...@gmail.com>.
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
> <ke...@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
Re: Store client data in server thread?
Posted by Anner van Hardenbroek <dw...@gmail.com>.
Groeten,
Anner.
--
Anner van Hardenbroek
dwlnetnl@gmail.com
On 6 mei 2010, at 06:04, Adam Simpkins <si...@facebook.com> wrote:
> I've been working on a patch to support this functionality by adding
> processor factories. It allows you to create a new handler object for
> each client connection. Your handler class can then store whatever
> connection-specific state it wants.
>
> When a new connection arrives, the server code calls the processor
> factory and passes in some context about the connection. The
> processor factory can always return a pointer to the same processor
> object, to be compatible with the current thrift behavior. However,
> you can also have it create a new processor+handler for each
> connection, to achieve the one-handler-per-connection behavior.
>
> One downside is that it requires some effort to update existing
> services to use this model if they've already been written to store
> global state in the handler object.
>
> So far my code is only for C++. It will probably be several more
> weeks at least before I'll have a patch ready to submit to the JIRA.
> (I think my change depends on some other C++ patches we've made at
> Facebook that still need to get pushed out to the JIRA first.)
>
> --
> Adam Simpkins
> simpkins@facebook.com
>
> On Wed, May 05, 2010 at 08:33:55PM -0700, 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
>> <ke...@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
Re: Store client data in server thread?
Posted by Anner van Hardenbroek <dw...@gmail.com>.
Hi,
First my appology for sending an empty mail. I'd like the idea of
custom handlers and stuff. Maybe it's worth looking if something like
Guice (an Depency Injector) can help. Also it might a good idea to let
the whole java library intergrate nicely with it.
I'm availabe for helping with a patch.
Regards,
Anner.
--
Anner van Hardenbroek
dwlnetnl@users.sourceforge.net
On 6 mei 2010, at 06:04, Adam Simpkins <si...@facebook.com> wrote:
> I've been working on a patch to support this functionality by adding
> processor factories. It allows you to create a new handler object for
> each client connection. Your handler class can then store whatever
> connection-specific state it wants.
>
> When a new connection arrives, the server code calls the processor
> factory and passes in some context about the connection. The
> processor factory can always return a pointer to the same processor
> object, to be compatible with the current thrift behavior. However,
> you can also have it create a new processor+handler for each
> connection, to achieve the one-handler-per-connection behavior.
>
> One downside is that it requires some effort to update existing
> services to use this model if they've already been written to store
> global state in the handler object.
>
> So far my code is only for C++. It will probably be several more
> weeks at least before I'll have a patch ready to submit to the JIRA.
> (I think my change depends on some other C++ patches we've made at
> Facebook that still need to get pushed out to the JIRA first.)
>
> --
> Adam Simpkins
> simpkins@facebook.com
>
> On Wed, May 05, 2010 at 08:33:55PM -0700, 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
>> <ke...@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
Re: Store client data in server thread?
Posted by Adam Simpkins <si...@facebook.com>.
I've been working on a patch to support this functionality by adding
processor factories. It allows you to create a new handler object for
each client connection. Your handler class can then store whatever
connection-specific state it wants.
When a new connection arrives, the server code calls the processor
factory and passes in some context about the connection. The
processor factory can always return a pointer to the same processor
object, to be compatible with the current thrift behavior. However,
you can also have it create a new processor+handler for each
connection, to achieve the one-handler-per-connection behavior.
One downside is that it requires some effort to update existing
services to use this model if they've already been written to store
global state in the handler object.
So far my code is only for C++. It will probably be several more
weeks at least before I'll have a patch ready to submit to the JIRA.
(I think my change depends on some other C++ patches we've made at
Facebook that still need to get pushed out to the JIRA first.)
--
Adam Simpkins
simpkins@facebook.com
On Wed, May 05, 2010 at 08:33:55PM -0700, 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
> <ke...@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
Re: Store client data in server thread?
Posted by Bjørn Borud <bb...@gmail.com>.
On Thu, May 6, 2010 at 5:33 AM, Bryan Duxbury <br...@rapleaf.com> 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).
>
I would like two things. I'd like a way to associate some properties with a
client session so that these properties are sent with every request -- much
like you can in HTTP with some client libraries. and of course, some way
of accessing these properties on the server end.
MyService.Client client = new MyService.Client(protocol);
client.putProperty("name", value);
Where the value can be a thrift structure.
The second thing I'd like is sort of the same as Kenny wants: a per-client
storage mechanism on the server end.
It might also be nice to have an API for hooking in code that can process a
request
before it gets sent by the client and before the request is dispatched in
the server, but if we get a mechanism for out-of-band data and per-client
(memory) storage on the server I'm a happy guy :-)
This would enable implementation of various authentication and authorization
schemes without the need for polluting APIs with this information. It would
also make it easier to change authentication strategies and implementations
without cluttering the APIs of services unnecessarily.
-Bjørn
Re: Store client data in server thread?
Posted by Bryan Duxbury <br...@rapleaf.com>.
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
<ke...@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
Re: Store client data in server thread?
Posted by Mayan Moudgill <ma...@bestweb.net>.
I'm assuming that each client uses a unique socket to connect. In that
case, why not store per-client information in a global socket-->data
map? It would be a shared structure, so you would have to do read/write
locks (or some lock-free equivalent) - or, if your load is light enough,
a simple mutex.
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
>