[erlang-questions] gen_server aggregating calls/casts

Robert Raschke rtrlists@REDACTED
Mon Jul 8 22:30:18 CEST 2013


A gen_server is there to handle a resource such that requests to that
resource are handled sequentially. It sounds like that doesn't quite match
your use case.

What you describe appears a little bit odd. Say you receive a request, and
now, before you handle it, you check if more of the same request type has
come in, and if they have, you add them in your "send results to" set. Now
what? Do you check again? Or are you satisfied you can actually do some
work?

Do you maybe want to memoize results? By adding results to your server
state, you could reply to identical(?) requests via lookup, leaving the
resource in peace.

Or do you require some kind of batching, only bothering the resource if
enough interest is present? Maybe augmented with some kind of time limit?
This would probably be a bit harder to implement.

Robby
On Jul 8, 2013 8:59 PM, "Jonathan Leivent" <jleivent@REDACTED> wrote:

> On 07/08/2013 03:40 PM, Sergej Jurecko wrote:
>
>> Easiest to explain with code:
>>
>> handle_call(Msg,From,State) ->
>> {noreply,State#rec{calls = [From | State#rec.calls}};
>>
>> handle_call(replyall,_,State) ->
>> [gen_server:reply(From,**SomeMessage) || From <-
>> lists:reverse(State#rec.calls)**],
>> {reply,ok,State}
>>
>> Queue instead of a list is probably better.
>>
>>
>> Sergej
>>
>
> As I said: "It can't accumulate calls into its state because there are
> other unrelated calls/casts it can encounter prior to seeing all of the
> currently queued matching calls."  Also, it will never get anything like
> your replyall call.
>
> Maybe I need two separate gen_server processes - one to just receive the
> requests and aggregate them into its state, then hand them off to the
> other, which handles both the aggregated requests and other calls/casts.
>
> -- Jonathan
>
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130708/67112c26/attachment.htm>


More information about the erlang-questions mailing list