Which version of thrift are you using more recent versions do away with all
intermediate processes, so you have to manage your own, at which point you
probably have a gen_server around your client anyway. So you can keep
state there.
Or maybe I'm not understanding.
-Anthony
On Mon, Feb 07, 2011 at 04:13:12PM -0400, Kenny MacDermid wrote:
> Thanks for the reply David,
>
> I could do state tracking using ETS, but I'm not sure how providing state
> tracking would require processing the requests serially.
>
> The thrift_processor is already in it's own process. So you should be able
> to have thrift_processor:loop(State0, ClientState0), and passed the state
> along to thrift_processor:handle_function(State0, ClientState0), call
> Handler:handle_function(Function, Params, ClientState0), and expected back
> {Result, ClientState1}.
>
> Do you see any reason why this wouldn't work? I'd have to modify the
> functions to take their state, and return it properly in handle_function,
> but that doesn't sound too difficult.
>
> Kenny
>
> On Mon, Feb 7, 2011 at 1:48 PM, David Reiss <[email protected]> wrote:
>
> > You can use ETS. Doing state tracking the way a gen_server does would
> > require processing requests serially, which is often unacceptable.
> >
> > --David
> >
> > On 02/05/2011 05:52 PM, Kenny MacDermid wrote:
> > > Hello,
> > >
> > > Is there a way to track client state in the erlang thrift service.
> > >
> > > Current it seems the thrift processor calls Handler:handle_function with
> > the
> > > function, and parameters, but no state.
> > >
> > > Am I missing something?
> > >
> > > Thanks,
> > >
> > > Kenny
> > >
> >
--
------------------------------------------------------------------------
Anthony Molinaro <[email protected]>
