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
