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 > >
