Re: [Cppcms-users] Simple long polling application has memory leaks (sockets left in CLOSE_WAIT state indefinitely)

[Artyom B. <art...@gm...>]

>
> Thanks, that seems to really address the heart of the issue.
>
> Just for clarification: async_on_peer_reset isn't automagically tracking
> the client timeout and performing some cleanup?  I think that was the
> fundamental assumption that I had that went wrong.  I expected that in
> this code:
>
>   void listen()
>   {
>       booster::shared_ptr<cppcms::http::context> context =
> release_context();
>       waiters_.insert(context);
>       context->async_on_peer_reset(
>           std::bind(
>               &chat::remove_context,
>               this,
>               context));
>   }
>
> the callback passed into async_on_peer_reset would get called on client
> timeout.  The documentation here:
> http://cppcms.com/cppcms_ref/latest/classcppcms_1_1http_1_1context.html#
> a0f6fe53deabd90fee0ced81a8df6404e
> seems to indicate that that is a valid expectation.
>

Yes and not:

if client closes the connection it is reported over TCP/IP to the
server and thus server can detect it and fire async_on_peer_reset.

There are two problems:

(a) if client does not cooperate and just gone - SO_KEEPALIVE timeout
settings of TCP/IP should be quite tight to detect an issue
(b) The server should report it to the FastCGI/SCGI application - and
it is actually the major problem. Most of the servers I tested didn't
do it reliably or did it on FastCGI but not SCGI or other way around.

Bottom line it shouldn't be considered reliable. It works well with
cooperative client with CppCMS's web server or web servers that
handle connections properly.

Artyom

P.S.: I was sure that I published a blog article regarding this but
I'm mistaken. So I probably need to write about it - how to detect a
client that gone.