Gen_server and multiple processes

Vladimir Sekissov svg@REDACTED
Fri Dec 20 12:17:24 CET 2002


Good day,

It seems I have what you need. It is the module `connection_pool' I
wrote some time ago. It consists from pool supervisor(ordinary
supervisor), pool manager and pool of servers. Client can request
server for operation and return server to pool after (explicitly or
implicitly on client exit). Varying supervisor and
manager parameters you can achieve the management policy you
want. Some features:

- prestarting minimal number of servers;
- pool size limit;
- shared servers - all clients are spreaded between servers;
- exclusive servers - one client per server, servers are
selected in round-robin manner.

Let me know and I'll send you code if you want.

Best Regards,
Vladimir Sekissov

hfventer> Thanks for all the advice so far
hfventer> 
hfventer> The system we have at the moment looks like this:
hfventer> We have several connections (TCP, but from different subsystem so they
hfventer> don't all speak the same protocol)  The message is sent to the
hfventer> appropriate translator to translate if from its native format to our
hfventer> internal representation of the data.  This representation is then sent
hfventer> off to be processed.  Once processing is finished a response is returned
hfventer> on the same communication medium that it came in on.
hfventer> With the curent gen_server implelentation (that works fine btw) there is
hfventer> a huge bottleneck, because the next message does not even start
hfventer> processing before the previous one hasn't completely finished its round
hfventer> trip.  Obviously this limmits the thoroughput.
hfventer> 
hfventer> Our gen_server is essentially stateless.  It recieves a message to do
hfventer> something with and sends a response.  If I understand most of the advice
hfventer> correctly a better way of doing things would be something like the
hfventer> following:
hfventer> Once a message is received it spawns a separate message_hanlder thread.
hfventer> This thread sends the message to the appropriate translator.  The
hfventer> translator spawns a worker thread to do the actual translation and
hfventer> immediately sends back a no_reply.  Once the translation is done, the
hfventer> correct response is sent back to the original worker thread.  This
hfventer> should free up the connection server to handle as many connections as
hfventer> the node has memory for and allow the translator to do its job as fast
hfventer> as it has processors to do it with.
hfventer> Would the list of spawned processes (workers or message_handlers)
hfventer> constitute the state of the gen_server now, or would that stil be
hfventer> supperfluous? (maybe for orderly shutdown purposes the list needs to be
hfventer> kept?  Would this be generaly good design or is there an easier way?)
hfventer> 
hfventer> This design patters is something that repeats several times in our
hfventer> system.  Is it possible to easily create our own behavior to make life
hfventer> easier for some of the newer programmers on the project?
hfventer> 
hfventer> Thanks to every one for your sage advice.
hfventer> 
hfventer> Heinrich



More information about the erlang-questions mailing list