Behavior when starting server on a used port

[Tonkpils]

So, I'm not sure exactly what the behavior is supposed to be but I started the server with mix server and I forgot I had a jekyll server running already on port 4000. The dynamo server started just fine and didn't complain but when I visited localhost:4000 the jekyll page showed up.

Shouldn't dynamo complain that the port is in use?

On the other hand, all I had to do was shut the jekyll app down and dynamo served just fine without restarting.

[josevalim]

Yeah, good call. Thanks!

[marshallshen]

Is anyone working on this? If not, I will work on a patch for this issue this weekend.

Just want to make sure I don't duplicate other people's work :)

[jni-]

I tried to do something, but I wasn't satisfied with it. If I remember well what I found, the start_listener in dynamo/lib/dynamo/cowboy.ex will return the same as gen_tcp from OTP : http://erlang.org/doc/man/gen_tcp.html. What I had done was to show a warning in the console, not cancel the whole thing. The port will be used by dynamo once freed, so I figured there was not reason to make it crash.

I won't have time to work on this again soon, but I hope this helps!

[marshallshen]

@jnl 👍

[akappen]

I tried to reproduce this and found that dynamo never attached to the conflicted port after killing the conflicting application. (The other comments here indicate they observed the opposite.)

1. start conflicting application on port 4000
2. start dynamo app:

$ mix server
Running DynamoTest.Dynamo at http://localhost:4000 with Cowboy on dev

3. kill conflicting application
4. http://localhost:4000 never responds

If I run mix server with no conflicting apps running everything works as expected.

---

I am new to elixir, so it may be that my local set-up is misbehaving and dynamo should continue trying to attach to a bound port. If that's the case I'll try to get my local env in shape before adding any new behavior.

---

When there is a port conflict, Dynamo.Cowboy.start_listener returns:

{:error,
 {{:shutdown,
   {:failed_to_start_child, :ranch_acceptors_sup,
    {{:badmatch, {:error, :eaddrinuse}},
     [{:ranch_acceptors_sup, :init, 1,
       [file: 'src/ranch_acceptors_sup.erl', line: 38]},
      {:supervisor, :init, 1, [file: 'supervisor.erl', line: 239]},
      {:gen_server, :init_it, 6, [file: 'gen_server.erl', line: 304]},
      {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 239]}]}}},
  {:child, :undefined, {:ranch_listener_sup, DynamoTest.HTTP},
   {:ranch_listener_sup, :start_link,
    [DynamoTest.HTTP, 100, :ranch_tcp, [port: 4000], :cowboy_protocol,
     [env: [dispatch: [{:_, [],
         [{:_, [], Dynamo.Cowboy.Handler, DynamoTest}]}]]]]}, :permanent, 5000,
   :supervisor, [:ranch_listener_sup]}}}

I'm not too familiar with ranch/cowboy, but should this (or any :error from :cowboy.start_http/s) be a terminal condition for dynamo start-up? Obviously logging the condition would be nice regardless.

[jni-]

@akappen Oddly enough, I see the same as you now. The "mix server" won't re-attach on its own, despite what I noted before. In this case, I second your suggestion to make this a fatal error. I see no point in adding complexity to dynamo simply to retry the port, it should simply fail I think.

[josevalim]

Fixed on master, thanks @jni-