[erlang-questions] EPmail-0.1 released

[Johan Wärlander]

Actually.. *ponder* Now that I describe what I was imagining would happen, I
realize it's not the case entirely. Sorry about that.

In case of a failure that actually causes the acceptor pool to restart (ie,
an acceptor child restarts several times in a short span of time), I'll end
up without acceptor children anyway because it's set up so that
em_listener:listen() must be called in order to start those up, but it's not
called automatically of course just because em_listener gets restarted.

Either way it should be fairly stable as the acceptor child processes are
very very simple, and if they suddenly die repeatedly then there's probably
some other issue going on with the system. But now I'll need to do some
thinking on how to make this work like I wanted it to, anyway, just so I can
be on the safe side.

//Johan

On Fri, Jan 28, 2011 at 9:02 PM, Johan Wärlander <johan@REDACTED> wrote:

> Hi Alexander,
>
> I'm also fairly new to Erlang, and I've tried a couple of different models
> for accepting TCP connections. The model I eventually arrived at was this:
>
> 1) Setting up an "acceptor supervisor", which starts a listener process and
> an acceptor pool supervisor in one_for_all mode.
> 2) When I call listen(Port, Acceptors) on the listener gen_server process
> it will gen_tcp:listen() and then start a number of child processes in the
> acceptor pool, which all wait in gen_tcp:accept() for incoming connections.
> 3) The acceptor pool is a simple_one_for_one supervisor, which will restart
> any of its acceptor processes if they die.
> 4) The acceptor child processes themselves have only this job: to wait for
> an incoming connection, then start an actual worker process (in your case
> the gen_fsm), and hand off the socket to that process. They will then go
> back to listening for the next incoming connection.
>
> Not sure if this is too complex a model (certainly others here will have
> opinions about that - do share!), but the reason I did it this way is that
> to me, it seems to provide better fault tolerance. If my acceptor child
> processes die for some reason, after a while the acceptor pool will restart
> itself. Since the top acceptor supervisor uses one_for_all strategy, it will
> then also restart the listener, which in turn reopens the listening socket
> and starts new acceptor child processes in the pool, getting us back to a
> known state.
>
> Feel free to have a look here:
> https://bitbucket.org/jwarlander/erlymud/src/cbf836ae2b6c/lib/erlymud/src/
>
> The files in question are em_acceptor_sup.erl (the top one_for_all acceptor
> supervisor), em_acceptor_pool.erl (the simple_one_for_one acceptor pool),
> em_acceptor.erl (acceptor child processes) and em_listener.erl (opening the
> listening socket and tells em_acceptor_pool to start acceptor child
> processes).
>
> Regards,
> Johan
>
>
> On Fri, Jan 28, 2011 at 6:30 PM, Alexander Kuleshov <
> kuleshovmail@REDACTED> wrote:
>
>> Hi to all,
>>
>> I startin to implement gen_fsm.
>>
>> When client connect to server by listen socket i started want to start
>> new gen_fsm for client request handling.
>>
>> I think i must create supervisor and started gen_fsm child every time
>> that i accept new connection.
>>
>> Is it true way?
>>
>> Thank you.
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>