Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iserve_server invalid state after acceptor abnormal exit #2

Open
alexgirao opened this issue Jan 29, 2011 · 0 comments
Open

iserve_server invalid state after acceptor abnormal exit #2

alexgirao opened this issue Jan 29, 2011 · 0 comments

Comments

@alexgirao
Copy link

Hi,

There is a bug in iserve/src/iserve_server.erl, this bug is also present in http://www.trapexit.org/A_fast_web_server_demonstrating_some_undocumented_Erlang_features article, it happens when the acceptor process (iserve_socket) receives two consecutives abnormal exists (easy to simulate in shell), upon the second exit, the function "handle_info({'EXIT', Pid, _Abnormal}, #state{acceptor=Pid} = State)" won't match and a new acceptor will not be created, silently stopping the service, the following patch solves the problem:

@@ -91,12 +91,12 @@ handle_info({'EXIT', Pid, normal}, #state{acceptor=Pid} = State) ->
 %% The current acceptor has died, wait a little and try again
 handle_info({'EXIT', Pid, _Abnormal}, #state{acceptor=Pid} = State) ->
     timer:sleep(2000),
-    iserve_socket:start_link(State#state.cb_mod, 
+    New_pid = iserve_socket:start_link(State#state.cb_mod, 
                              State#state.cb_data, 
                              self(), 
                              State#state.listen_socket, 
                              State#state.port),
-    {noreply, State};
+    {noreply, State#state{acceptor=New_pid}};

 handle_info(_Info, State) ->
     {noreply, State}.

Alexandre Girao
https://github.com/alexgirao

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant