Connection never recovered sometimes [Java]

[DarioCrivelli]

The pattern is strange, because the first attempt fails in 8 seconds, the second one fails immediately, then the subsequent ones fail after 30 seconds (which is the default connection timeout).

If you can replicate the issue locally, please expand the log, by configuring the level for the "com.lightstreamer.ls_proxy.connection", "com.lightstreamer.ls_client.session", and "com.lightstreamer.ls_client.stream" loggers as FINER, then attach the log.
This should clarify what happens during the connection attempts.

[romainmoreau]

Thanks for your answer, I can't replicate on demand but I modified the levels and I will post here the log when it happens again ; until now, it was at most once a week.

[romainmoreau]

It seems like the server is being rebooted ; since the password I use is dynamic (session related) and the old one is used to reconnect, the following behaviour keeps happening :

2015-03-07 00:40:51.707  INFO 29175 --- [Stream-sense queue] com.lightstreamer.ls_proxy.connection    : Retry after reconnection failure
2015-03-07 00:40:51.707 DEBUG 29175 --- [Stream-sense queue] com.lightstreamer.ls_proxy.connection    : Connection attempt for https://xxxx.com - NO CONSTRAINTS
2015-03-07 00:40:51.708  INFO 29175 --- [Stream-sense queue] f.r.ig.common.AbstractStreamingClient    : Connecting
2015-03-07 00:40:51.708 DEBUG 29175 --- [Background connection opening] com.lightstreamer.ls_proxy.connection    : Opening new connection
2015-03-07 00:40:51.709 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.session      : Connecting for a new session
2015-03-07 00:40:51.710 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.protocol     : Opening stream connection
2015-03-07 00:40:51.710 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.protocol     : Connection params: {LS_password=XXXXXXXXXXXXX, LS_adapter_set=DEFAULT, LS_content_length=50000000, LS_report_info=true, LS_user=XXXXXXXX}
2015-03-07 00:40:51.710 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.stream       : Opening connection to https://xxxx.com/lightstreamer/create_session.txt
2015-03-07 00:40:51.817 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.session      : Starting new session
2015-03-07 00:40:51.818 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.actions      : Notifying an exception on the current connection
2015-03-07 00:40:51.818 DEBUG 29175 --- [Thread-121] com.lightstreamer.ls_client.stream       : Closing create connection
2015-03-07 00:40:51.819 DEBUG 29175 --- [Thread-120] com.lightstreamer.ls_proxy.connection    : Failed to open new connection
2015-03-07 00:40:51.819  INFO 29175 --- [Thread-120] f.r.ig.common.AbstractStreamingClient    : Disconnected
2015-03-07 00:40:51.819 DEBUG 29175 --- [Stream-sense queue] com.lightstreamer.ls_proxy.connection    : Connection attempt unsuccessful for https://xxxx.com - NO CONSTRAINTS
2015-03-07 00:40:51.819  WARN 29175 --- [Stream-sense queue] com.lightstreamer.ls_proxy.connection    : Reconnection attempt failure
2015-03-07 00:40:51.819 DEBUG 29175 --- [Stream-sense queue] com.lightstreamer.ls_proxy.connection    : Reconnection attempt failure
com.lightstreamer.ls_proxy.ConnectException: User/password check failed
    at com.lightstreamer.ls_proxy.ConnectionHandler$1.run(ConnectionHandler.java:319)

The problem is that my client doesn't know that it needs to recreate a new password because the only callbacks called are PushStatusListener.onConnecting and PushStatusListener.onDisconnected (highlighted in bold in the previous log).

How could my client find out that the reconnection attempt failure is because of a user/password check failed ?

[DarioCrivelli]

I see; the simple recovery mechanism offered by the ls_proxy layer is too simple for this case.
This means that you cannot take advantage of the internal reconnection loop that follows when you set connectionRetryTimeoutMillis to a nonzero value.
By setting connectionRetryTimeoutMillis to 0, your code will receive a onFailedReconnection invocation on the PushErrorListener, with a suitable PushException. Then, by invoking rethrow() on this exception, you will get the original PushUserException with the relevant error code, based on which you should setup the proper recovery action.
Sorry for the hassle.

[romainmoreau]

No problem, thanks for your help.