Strange behaviour with LSProxy [Java]

Hello,

I recently observed a weird behaviour with LSProxy.

At the beginning, the session stalled.
So the LSProxy tried to reconnect and it seems like a new session is succesfully started.
The strange behaviour is when I receive updates during this new session: for each update received, there are a lot of logs that are outputted and this pattern keeps continuing.

Code:

---

2015-08-31 17:24:23.269 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.protocol    : Request successful
2015-08-31 17:24:23.269 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.protocol    : Reading stream connection info
2015-08-31 17:24:23.271 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.session      : Rebind successful on session S**********************2
2015-08-31 17:24:23.271 TRACE 1360 --- [Lightstreamer listening thread] f.r.ig.common.AbstractStreamingClient    : New update for ITEM1
2015-08-31 17:24:23.271 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.protocol    : Got notification for response content length reached
2015-08-31 17:24:23.271 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.session      : Rebinding session S**********************2
2015-08-31 17:24:23.271 DEBUG 1360 --- [Lightstreamer listening thread] com.lightstreamer.ls_client.protocol    : Opening stream connection to rebind current session

---

Even though the log lines level is not critical, it seems like something odd.
What are the meaning of this logs and do they affect the streaming in any way?

Thanks.

The new session must have been opened in long polling.
Unless instructed to enforce it, the LSProxy uses long polling when it fails opening a streaming connection.
This is done to overcome cases in which streaming connections are not supported, but in case of a temporary block at network level, it is possible that our heuristics get deceived and that long polling is chosen also when not needed.

You can make sure of what happens by consulting the ConnectionStatusListener: after onStalled, you should notice a call to onPolling.
If your client application is certain that streaming is possible (for instance, because it was used previously), it could force a disconnection and reconnection, which hopefully will select streaming mode; LSProxy does not do that autonomously.

As far as the log is concerned, you have enabled a very fine-grained log, which logs upon each poll, hence it can become huge.
Unfortunately, it is not possible to have the LSProxy log differently in case of streaming or polling.
Again, only the application could perhaps overcome, by changing dynamically the log settings based on the context.

Apart from some inefficiency, the use of long polling may not affect the update flow.
Only in case of a high update rate you may observe some delays.

Hello Dario,

Thanks for your detailed anwser.

That's right; I did not paid attention to it but the onPolling method of my PushStatusListener was indeed called whereas the onStreaming method is usually called.

The algorithm you are talking about, isn't it the feature called Stream-sense in the Javadoc?
If I disable it like in the following code, shouldn't the streaming always be chosen, even for a reconnection?

Code:

---

LSProxy lSProxy = new LSProxy(...);
ConnectionInfo connectionInfo = new ConnectionInfo();
connectionInfo.enableStreamSense = false;
lSProxy.startPushConnection(connectionInfo);

---

Hi,

You are right; indeed there is also this option.
If you are confident that HTTP streaming is supported by the client environment, you can also enforce that all connection attempt will be in HTTP streaming by suppressing the Stream-sense.

By the way, let me remark that the brand new Java client library that is going to replace the current one has been released as a beta.
So, we suggest you considering and preparing a port, also because we are confident that the new interface is more handy and more powerful. See the relevant information here.

Hello Dario,

Thanks for the confirmation.

Will this new API be compatible with servers in version 5.1.2?
It is stated here that it is currently "compatible with Server since 6.0.1".

Yes, I confirm that a Server upgrade is needed and there are no plans to make the new library backward-compatible.
If you are concerned about upgrading to Server 6, consider that we have made available an online tool to assist the porting task, as explained in the release notes.

Hello Dario,

Thanks for your precisions.