You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Brian McKinney <br...@reframeit.com> on 2009/12/09 20:18:32 UTC
Passing state to Handler:handle_function (Erlang)
Currently, the callback for the handler under Erlang is defined as follows;
handle_function(Function, Args)
It would be nice to propagate state between calls so I could collect metrics and pass in config information. There are other ways to do this like wrapping the handler in a gen_server but it would be very convenient (and simplify things greatly) if the semantics of handle_function are changed to:
handle_function(Function, Args, State) ->
{ok, State} | {reply, Reply, State}
Cheers,
Brian McKinney
Re: Passing state to Handler:handle_function (Erlang)
Posted by Eugene Letuchy <el...@facebook.com>.
I second/third Todd's recommendation -- the design of an Erlang Thrift handler
is as a module, _not_ as a process. gen_server:cast (or just the ! operator) is
the way to go.
- Eugene
On 12/9/09 11:38 AM, Todd Lipcon wrote:
> Hey Brian,
>
> What I'd suggest for maintaining per-server config is simply using ets or
> mnesia.
>
> For maintaining stats, I'd use gen_server:cast(...) to send increments to a
> centralized gen_server which maintains the state. If you have that server
> store its metrics in mnesia, you can even expose them over SNMP pretty
> easily.
>
> -Todd
>
> On Wed, Dec 9, 2009 at 11:34 AM, Brian McKinney<br...@reframeit.com> wrote:
>
>> Hi Todd,
>> That is a good question. In my original thinking, per connection doesn't
>> make sense since I am interested in per server config and global metrics
>> (e.g. number of requests served). David's response along with your
>> explanation makes it clear why a per server State would be plain bad (and
>> clarifies design going forward as we do more work at Reframe It in Erlang
>> vis a vis Thrift).
>> I've already written the code to do the above so it is not a big deal just
>> a question that was nagging me.
>>
>> Thanks to both David and you for a quick response.
>>
>> Brian
>>
>> On Dec 9, 2009, at 12:22 PM, Todd Lipcon wrote:
>>
>>> Hi Brian,
>>>
>>> Would you expect state to be a per-connection thing, a per-server thing,
>> or
>>> what? The former is reasonably possible, but the latter would force all
>>> requests to be serialized to a single Erlang process.
>>>
>>> -Todd
>>>
>>> On Wed, Dec 9, 2009 at 11:18 AM, Brian McKinney<br...@reframeit.com>
>> wrote:
>>>
>>>> Currently, the callback for the handler under Erlang is defined as
>> follows;
>>>>
>>>> handle_function(Function, Args)
>>>>
>>>> It would be nice to propagate state between calls so I could collect
>>>> metrics and pass in config information. There are other ways to do this
>>>> like wrapping the handler in a gen_server but it would be very
>> convenient
>>>> (and simplify things greatly) if the semantics of handle_function are
>>>> changed to:
>>>>
>>>> handle_function(Function, Args, State) ->
>>>> {ok, State} | {reply, Reply, State}
>>>>
>>>> Cheers,
>>>>
>>>> Brian McKinney
>>
>>
Re: Passing state to Handler:handle_function (Erlang)
Posted by Todd Lipcon <to...@cloudera.com>.
Hey Brian,
What I'd suggest for maintaining per-server config is simply using ets or
mnesia.
For maintaining stats, I'd use gen_server:cast(...) to send increments to a
centralized gen_server which maintains the state. If you have that server
store its metrics in mnesia, you can even expose them over SNMP pretty
easily.
-Todd
On Wed, Dec 9, 2009 at 11:34 AM, Brian McKinney <br...@reframeit.com> wrote:
> Hi Todd,
> That is a good question. In my original thinking, per connection doesn't
> make sense since I am interested in per server config and global metrics
> (e.g. number of requests served). David's response along with your
> explanation makes it clear why a per server State would be plain bad (and
> clarifies design going forward as we do more work at Reframe It in Erlang
> vis a vis Thrift).
> I've already written the code to do the above so it is not a big deal just
> a question that was nagging me.
>
> Thanks to both David and you for a quick response.
>
> Brian
>
> On Dec 9, 2009, at 12:22 PM, Todd Lipcon wrote:
>
> > Hi Brian,
> >
> > Would you expect state to be a per-connection thing, a per-server thing,
> or
> > what? The former is reasonably possible, but the latter would force all
> > requests to be serialized to a single Erlang process.
> >
> > -Todd
> >
> > On Wed, Dec 9, 2009 at 11:18 AM, Brian McKinney <br...@reframeit.com>
> wrote:
> >
> >> Currently, the callback for the handler under Erlang is defined as
> follows;
> >>
> >> handle_function(Function, Args)
> >>
> >> It would be nice to propagate state between calls so I could collect
> >> metrics and pass in config information. There are other ways to do this
> >> like wrapping the handler in a gen_server but it would be very
> convenient
> >> (and simplify things greatly) if the semantics of handle_function are
> >> changed to:
> >>
> >> handle_function(Function, Args, State) ->
> >> {ok, State} | {reply, Reply, State}
> >>
> >> Cheers,
> >>
> >> Brian McKinney
>
>
Re: Passing state to Handler:handle_function (Erlang)
Posted by Brian McKinney <br...@reframeit.com>.
Hi Todd,
That is a good question. In my original thinking, per connection doesn't make sense since I am interested in per server config and global metrics (e.g. number of requests served). David's response along with your explanation makes it clear why a per server State would be plain bad (and clarifies design going forward as we do more work at Reframe It in Erlang vis a vis Thrift).
I've already written the code to do the above so it is not a big deal just a question that was nagging me.
Thanks to both David and you for a quick response.
Brian
On Dec 9, 2009, at 12:22 PM, Todd Lipcon wrote:
> Hi Brian,
>
> Would you expect state to be a per-connection thing, a per-server thing, or
> what? The former is reasonably possible, but the latter would force all
> requests to be serialized to a single Erlang process.
>
> -Todd
>
> On Wed, Dec 9, 2009 at 11:18 AM, Brian McKinney <br...@reframeit.com> wrote:
>
>> Currently, the callback for the handler under Erlang is defined as follows;
>>
>> handle_function(Function, Args)
>>
>> It would be nice to propagate state between calls so I could collect
>> metrics and pass in config information. There are other ways to do this
>> like wrapping the handler in a gen_server but it would be very convenient
>> (and simplify things greatly) if the semantics of handle_function are
>> changed to:
>>
>> handle_function(Function, Args, State) ->
>> {ok, State} | {reply, Reply, State}
>>
>> Cheers,
>>
>> Brian McKinney
Re: Passing state to Handler:handle_function (Erlang)
Posted by Todd Lipcon <to...@cloudera.com>.
Hi Brian,
Would you expect state to be a per-connection thing, a per-server thing, or
what? The former is reasonably possible, but the latter would force all
requests to be serialized to a single Erlang process.
-Todd
On Wed, Dec 9, 2009 at 11:18 AM, Brian McKinney <br...@reframeit.com> wrote:
> Currently, the callback for the handler under Erlang is defined as follows;
>
> handle_function(Function, Args)
>
> It would be nice to propagate state between calls so I could collect
> metrics and pass in config information. There are other ways to do this
> like wrapping the handler in a gen_server but it would be very convenient
> (and simplify things greatly) if the semantics of handle_function are
> changed to:
>
> handle_function(Function, Args, State) ->
> {ok, State} | {reply, Reply, State}
>
> Cheers,
>
> Brian McKinney
Re: Passing state to Handler:handle_function (Erlang)
Posted by David Reiss <dr...@facebook.com>.
If I recall correctly, handle_function is called from multiple processes
so that a server can handle multiple requests at once. Therefore, it is
not really possible to maintain a single state between calls.
--David
Brian McKinney wrote:
> Currently, the callback for the handler under Erlang is defined as follows;
>
> handle_function(Function, Args)
>
> It would be nice to propagate state between calls so I could collect metrics and pass in config information. There are other ways to do this like wrapping the handler in a gen_server but it would be very convenient (and simplify things greatly) if the semantics of handle_function are changed to:
>
> handle_function(Function, Args, State) ->
> {ok, State} | {reply, Reply, State}
>
> Cheers,
>
> Brian McKinney