<p dir="ltr">Don't feel too bad about breaking modularity like that - I must confess I've done that a couple of times. One of those times it even took the form of a "prioritizing_server" overlay on gen_server.</p>

<div class="gmail_quote">Den 09/07/2013 19.23 skrev "Jonathan Leivent" <<a href="mailto:jleivent@comcast.net">jleivent@comcast.net</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/08/2013 07:27 PM, Robert Raschke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you considered using a queuing framework, like RabbitMQ?<br>
</blockquote>
<br>
What I'm trying to implement is too low level to make use of RabbitMQ. Ideally, if this works, it would be used within such frameworks.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
<br>
Alternatively, you'll probably want to double layer your server, as was<br>
previously suggested.<br>
</blockquote>
<br>
I think that will eventually be my best option - especially as I just learned that Erlang does no inter-node flow control on its own.  So, the outer layer will have to both aggregate requests AND flow control them as well, as there may be a very large number of requests coming from a very large number of clients.<br>

<br>
It's surprising to me that Erlang provides no built-in flow control, since it is using TCP.  A gen_server that just receives and aggregates messages on a list could end up using a lot of memory with no way to push back.<br>

<br>
My gen_server can actually tolerate having incoming requests dropped more than it can tolerate having aggregation use up lots of memory (potentially dying if it runs out, or at least slowing things down). Maybe that means I will need to use gen_UDP - I knew I would eventually switch to UDP to bypass the TCP overhead, but now that looks like a sooner-rather-than-later project.<br>

<br>
For now, I cheated and used gen_server's internal message format - just because doing that turns out to perturb the code I already have the least.  All it takes is:<br>
<br>
aggregate_requests(L) -><br>
  receive<br>
    {'$gen_call', From, R={request, _}} -><br>
      aggregate_requests([{From, R}|L])<br>
  after 0 -> L<br>
  end.<br>
<br>
That's just too tidy and easy to pass up, even if it does break modularity.  I know I'll have to replace this when I face the flow-control issue.<br>
<br>
-- Jonathan<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div>