Initially recommended by Magnus Klaar, the trick is to add a catch
instruction before the erlang:hibernate/3 call so that Dialyzer
thinks it will return, followed by the expected return value
('ok' for HTTP, 'closed' for websockets).
This should be good enough until a real solution is found.
We've been having many recurring issues, some which were fixed,
only to have other things broken again. Can't rely on a service
that breaks all the time.
This allows any application to upgrade the protocol options without
having to restart the listener. This is most useful to update the
dispatch list of HTTP servers, for example.
The upgrade is done at the acceptor level, meaning only new connections
receive the new protocol options.
This is a big change in the internal cowboy API. This should not
have any impact on existing applications as only the acceptor is
expected to use these API calls.
The function cowboy_listener:wait/3 has been removed. max_connections
checking now occurs directly in cowboy_listener:add_connection/3.
If the pool is full and the acceptor has to wait, then it doesn't
return, waiting for a free space to be available.
To accomodate these changes, it is now cowboy_listener that will
inform the new connection that it is ready by sending {shoot, self()}.
This should be a great improvement to the latency of responses as
there is one less message to wait for before the request process
can do its work.
Overall the performance under heavy load should also be improved as
we greatly reduce the number of messages sent between the acceptor
and the listener process.
We're using the existing test suite for websocket servers from the
Autobahn project to verify that out websockets implementation is
sane. A CT test suite and python module wrapping the test suite has
been added. The test suite is run when the 'make inttests' target
is executed.
We try to send a 500 error only if we didn't send the response
headers yet. If they were, then we have no way to be sure the
response was fully sent, nor should we assume anything about
how this will be handled client-side, so we do nothing more
and in both cases close the connection.
