Error while shutting down async WebSocket++-Server

[Ukilele]

Hello zaphoyd,

I am using your library WebSocket++. It works perfectly fine for me and has a great interface. But there is one issue, which you can see in the attached file: WebSocket++ShutdownError.png

The error occures, when the destructor of my class WebSocketppWrapperImpl gets called. Especially in line 73 when calling m_asyncRun.wait(). You can find the class definition attached in: WebSocketppWrapperImpl.txt

WebSocketppWrapperImpl.txt

All I do is, create an instance of that type and after that call the destructor (implicitly). I am using asio 1.10.6 - standalone. It would be great if you could provide me some help.

Best Regards Ukilele

[Ukilele]

As the attached image seems to be very small, here is its content:

[2016-05-24 16:46:19] [info] asio handle_accept error: asio.system:995 (Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsa nforderung abgebrochen.) [2016-05-24 16:46:19] [info] Error getting remote endpoint: asio.system:10009 (Das angegebene Dateihandle ist ung³ltig.) [2016-05-24 16:46:19] [info] asio async_shutdown error: asio.system:10009 (Das angegebene Dateihandle ist ung³ltig.) [WebSocketppWrapper.cpp, 55]: FAIL HANDLER [2016-05-24 16:46:19] [error] handle_accept error: Underlying Transport Error [2016-05-24 16:46:19] [info] Stopping acceptance of new connections because the underlying transport is no longer listening.

[zaphoyd]

Is the error actually causing problems? or are you just worried about the messages in the log?

Unless there is specific problem I believe that this is the currently expected behavior. Because of the very loose coupling between them the core library doesn't get granular error information from the transport layer. It sees "transport layer reported some error" and outputs the "Underlying Transport Error" which generally means "I don't know what happened, ask the transport layer for details". The transport layer outputs all those other lines providing the details that the core library didn't have.

Note that all of the lines printed by the transport layer are info level notices. This is how the library reports conditions that are "errors" but that are expected. I.e. if you get an operation cancelled error after explicitly or implicitly stopping listening it gets flagged as info level. If you were to get that condition when the library wasn't expecting it the level would be error or fatal.

There definitely is some room for improvement here on the log messaging. There is a balance to strike between providing specific information about routine conditions and noisiness. Perhaps some of these should be devel level rather than info. Some of these conditions (including the fail handler trigger) also happen because a new connection_hdl is created prior to accepting a new TCP socket. As a result, when an endpoint stops listening it has to dispose of an entire unused connection_hdl.

[Ukilele]

Hello zaphoyd, thank you very much for your prompt response!

I am just worried about the messages, it seems not to cause any problems. I thought that I maybe could have used your API wrong. Then I will just ignore the messages :)