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<[email protected]> 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<[email protected]>
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
