Connection state machine problem

[Max Dmitrichenko]

Hi!

I've got application abort caused by an exception thrown in the io_service thread from the method 

#6  0x00007ff21c2eb414 in websocketpp::connection<websocketpp::config::asio_tls>::atomic_state_change (this=<value optimized out>, internal_req=websocketpp::session::internal_state::READ_HTTP_RESPONSE, msg=<value optimized out>, external_dest=<value optimized out>, 

    external_req=<value optimized out>, internal_dest=<value optimized out>) at /srv/bender2/slave/release/build/3rdParty/env-Debian-6.0.5/include/websocketpp/impl/connection_impl.hpp:1609

#7  0x00007ff21c356529 in websocketpp::connection<websocketpp::config::asio_tls>::handle_read_http_response (this=0xe86320, ec=<value optimized out>, bytes_transferred=129)

    at /srv/bender2/slave/release/build/3rdParty/env-Debian-6.0.5/include/websocketpp/impl/connection_impl.hpp:1325

As far as I can see, m_state == state::closed, while it is required to state::connecting. Any thoughts how it should be handled?

--

WBR,

  Max

[geoff.l...@gmail.com]

I think I am also seeing this problem.

m_state: state::closed

m_local_close_code: 1006 (abnormal_close)

m_local_close_reason: "The opening handshake timed out"

In my case the server is under high load explaining the timeout. The client throws the "invalid state" exception and exits. The abnormal_close description suggests this state is not a result of messages passed between client/server. Rather the client is giving up on the server and initiating the closing of the connection. So as far as I can work out, in this scenario it is possible to receive the handshake response while in the closed state.  

In my opinion it would be better for the state machine to ignore the message rather than terminate.

A workaround is to try and avoid the situation by making the timeouts longer.

regards

Geoff

[Peter Thorson]

Hi Geoff,

I agree that a client connection failing due to a timeout should not result in an invalid state exception. I’ve created an issue on GitHub to track this: https://github.com/zaphoyd/websocketpp/issues/389

Best,

Peter

--
You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Dmitrichenko]

On Tuesday, December 9, 2014 3:38:47 AM UTC+3, Peter Thorson wrote:

I’ve created an issue on GitHub to track this: https://github.com/zaphoyd/websocketpp/issues/389

Wow! I've thought this issue was fixed upstream long time ago ) Almost a year passed since then ) 

[Peter Thorson]

Max: It seems your bug report here fell through the cracks. My apologies.

The error checking system for the handshake state machine was old and leftover from the 0.2 branch and tended to fail in bad ways, particularly it worked on an assert model under the idea that state errors were only possible if the library was being used incorrectly and practically caused exceptions to be thrown that bubbled out of io_service.run() and were very hard to deal with. I’ve gutted it and replaced it with something based on the 0.3.x style error handling system.

Even though these errors should never happen in normal use they will now be treated as standard recoverable errors that will log what happened and terminate the connection, but not affect other connections. As such there should be no way for the core library to throw an exception out of io_service.run() or any other non-handler transport method now (hurray). In addition, based on some testing and these reports I identified the cases where these state errors were happening in normal use (basically if a timeout handler was called immediately before the read/write that would have completed the handshake the state was closed instead of connecting and the library got confused). Those cases are now identified and properly dealt with. You’ll either have a timeout or not and not both.

Geoff - If you could check out the latest develop branch and let me know if that fixes your issue it would be helpful.

[Geoff Lambourne]

Hi Peter.  Great work.  I wish I could be as responsive.  We are actually running a 0.3.x version of the library and the issues was being intermittently seen on a customer system. We have patched this version to avoid these scenarios and made some performance improvements (of non-websocketpp components) to reduce the load and the likelihood of it occurring.  We will upgrade to a 0.4.x version with the fix before next release and try to test it then on a test system under load.  Probably not until around February.