Results 1 to 7 of 7
  1. #1

    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.

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    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.

  3. #3
    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);

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    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.

  5. #5
    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".

  6. #6
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    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.

  7. #7
    Hello Dario,

    Thanks for your precisions.

 

 

Similar Threads

  1. itemUpdate.getNewValue throws strange exception
    By mnenchev in forum Client APIs
    Replies: 1
    Last Post: October 28th, 2010, 10:36 AM
  2. Strange Error on item update
    By mnenchev in forum Client APIs
    Replies: 10
    Last Post: March 19th, 2010, 09:57 AM
  3. Browser Popup Focus Behaviour on Safari (on Mac)
    By ctranfd in forum Client APIs
    Replies: 3
    Last Post: August 31st, 2009, 09:07 AM
  4. Replies: 1
    Last Post: May 21st, 2009, 10:41 AM
  5. Strange FireFox error
    By jameswolfe in forum Client APIs
    Replies: 5
    Last Post: August 27th, 2007, 02:24 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 05:07 AM.