Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30
  1. #11
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Quote Originally Posted by DarioCrivelli
    First of all, in the attached file you mention a value of 10 ms for <session_timeout_millis>, but I assume you mean 10 seconds.
    Yes it is 10 seconds. not 10 ms.

    Quote Originally Posted by DarioCrivelli
    Indeed, your client seems to be receiving a lot of data to be elaborated, about 300KB in 15 seconds at least.
    This may cause the browser to be overwhelmed. May you please confirm that by direct observation of the client machine?

    This would explain the "Sync error", as the page would issue the request of rebinding to the session long time after the previous connection has closed.
    Server is sending approximately 80 KB in first control request

    and After adding tables to page, it is expected upto 170 KB of data to be pushed in second request.

    In such case, If we use default 5 seconds session_timeout_millis and 300 KB of content-length will be ok?

    Quote Originally Posted by DarioCrivelli
    Note that you might increase the <session_timeout_millis> and the content-length, but that would just postpone the problem. In fact, in the third case (with the increased content-length), before the whole content-length has been consumed, the client opens a new session in polling mode. This is a recovery mechanism adopted by Lightstreamer web client library when it detects that the update processing is slower than the incoming update rate.
    Because as you said, increasing session_timeout_millis and the content-length just postpones the issue.

    Please giude me to handle this situation.

  2. #12
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    972
    If you confirm that the client page is slow at elaborating the huge amount of data, then that is the main problem.
    The bottleneck may not involve Lightstreamer library at all, depending on which kind of elaboration the page performs.

    Does your page only display pushed data on the screen through one of the provided Visual Tables?
    Is the big flow of pushed data limited to the snapshots or is it continuous?

    As a first attempt, you may force POLLING mode from your client. In polling, the client asks the Server for new updates only after it has finished elaborating the updates already received, thus forcing more filtering on the server side.
    However, this is only beneficial if filtering is allowed by your subscriptions (i.e. RAW mode or the "unfiltered" flag are not used by the client).

  3. #13
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Actually I am trying to use NotifySessionClose event to logoff the user in LS. But due to above problem, the user getting logged on and off continuously.

    To solve this, I need your guidance to find proper place where and how I can identify Browser close.

    Or I have to solve this session getting closed continuously when server push this data subscribed by user.

    Quote Originally Posted by DarioCrivelli
    If you confirm that the client page is slow at elaborating the huge amount of data, then that is the main problem.
    The bottleneck may not involve Lightstreamer library at all, depending on which kind of elaboration the page performs.

    Does your page only display pushed data on the screen through one of the provided Visual Tables?
    Is the big flow of pushed data limited to the snapshots or is it continuous?
    My client page has single push engine which has 2 Non-Visual tables to get subscriptions. Subscriptions are sent and received with DISTINCT mode. In each subscription maximum of 10KB of data is transferred.

    We cant say big flow of data. Max 10 KB of data pushed continuously. Not using shapshots.

    But anyway status changed to Polling when we start subscription by default.
    Do you mean we have to use POLLING mode during engine creation?

    Thanks & Regards,
    Krishna

  4. #14
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Thanks DarioCrivelli.

    Creating lsengine with POLLING mode solved the issue of session close and create new session and Sync Error.

    But Can you confirm me if this is right place to handle Browser Close event at NotifySessionClose?

  5. #15
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    972
    The browser can close abruptly and LS does not try to trace the event.

    When a browser closes, the Server eventually notices that the client has disappeared and closes the session by timeout. This may happen quite a long time after the browser close (in the next release of LS, more effort will be spent in order to close the session as soon as possible after a browser close).

    Nevertheless, the notifySessionClose is the only place where the event can be hooked.
    As you have experienced, a session can be closed also for other reasons and in some cases a new session has just replaced it, so you cannot directly relate session close and browser close.



    As, according to your log, a content-length of 300 KB was consumed in less than 15 seconds, the load on the client may be higher than you think.
    Note that if there were any bottleneck that you could remove, regarding the data elaboration on the page, then you could restore streaming mode.

  6. #16
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Hi DarioCrivelli,

    I have created a page with lsengine and 2 non-visual push tables.

    When user login successfully, about 900KB of data pushed to first push table in single subscription. Then 10 to 120 of market watch details of 10 KB each are subscribed through second non-visual table. Market watch details are pushed one by one each of 10 KB when received by the server (Not altogether).

    Streaming mode works fine when only 10 market watch details are subscribed. For more than that, I was getting Sync error as mentioned in above posts.

    Polling mode works when it subscribes more, but still, it also doesn't work for 120 market watch details subscription.

    Hope it ends up with bottleneck at client. If this can be handled by changing content-length? Is there any other way to handle this case in such way to remove the bottleneck at client?

  7. #17
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    972
    The content-length setting should play no role in your streaming issue.

    In polling, the content-length may limit the size of the response to a poll. This doesn't happen in a normal case, but if you handle such big data, this limitation may come into play.
    This may cause the Server to need more or less polls to dequeue the snapshots.
    Yours is an uncommon case and, honestly, I can't guess whether limiting the size of a polling response could be beneficial.
    Anyway, if a single event were responsible for the 900KB of snapshot data caused by your first subscription, they would be sent in a single poll, regardless of the content-length configuration.

    What does it happen with 120 market watch detail subscriptions in long polling?
    Do you still notice "sync error" messages? Or is it just too slow to be acceptable?

    With 120 market watch detail subscriptions, the processing of the updates in your custom code may be heavy; I suppose that the client CPU usage is at 100%.
    However, Lightstreamer library itself may need a lot of processing time. Please try removing all your callbacks from the NonVisualTables and see if the client CPU usage is still at 100%.

  8. #18
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Quote Originally Posted by DarioCrivelli
    What does it happen with 120 market watch detail subscriptions in long polling?
    Do you still notice "sync error" messages? Or is it just too slow to be acceptable?
    By Long Polling do you mean increased Polling interval (max_polling_millis)?
    If yes, I have tried increasing max_polling_millis, even with 60 seconds, I am getting same Sync Error when market watch details are pushed.

    Quote Originally Posted by DarioCrivelli
    With 120 market watch detail subscriptions, the processing of the updates in your custom code may be heavy; I suppose that the client CPU usage is at 100%.
    However, Lightstreamer library itself may need a lot of processing time. Please try removing all your callbacks from the NonVisualTables and see if the client CPU usage is still at 100%.
    Even with 120 market watch details, it takes maximum of 50% of CPU. It takes 0 to 2% normally, and 50% while processing and showing it.

  9. #19
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    972
    I wrote "Long Polling" as another name for the "Asynchronous Polling", which, in an Ajax context, can be named as just "Polling".
    So, I just referred to your previous post, in which you had reported the behavior of the polling case.
    In polling mode, we expect that the browser, if overwhelmed by the processing of the outcome of a poll request, delays the next poll request (but we have no control on what the browser actually chooses to delay).
    This would avoid that the updates queue up on the client: they would try to queue up on the Server, which, however, can conflate them.

    If the next request is delayed too long, the Server will have discarded the Session and will get a "sync error".
    The client tries heuristically to measure its own processing delay and may request the Server to delay the Session discarding. Your setting of <max_polling_millis> is correct, because it avoids that the Server refuses to obey a client delay request which is too long.
    However, the client heuristic may be underestimating the delay.

    May we check your Server log taken during a polling run with 120 market watch details?
    You should set the priority of the LightstreamerLogger.requests.polling logger to INFO.

    If you see the CPU usage steadily at 50%, it may be that only half of the available processors can be used by the browser; hence, this would still represent a bottleneck.
    You could still try removing all your callbacks from the NonVisualTables and see if the client CPU usage is still at 50%.

  10. #20
    Member
    Join Date
    Apr 2010
    Location
    Madurai
    Posts
    11
    Quote Originally Posted by DarioCrivelli
    I wrote "Long Polling" as another name for the "Asynchronous Polling", which, in an Ajax context, can be named as just "Polling".
    So, I just referred to your previous post, in which you had reported the behavior of the polling case.
    In polling mode, we expect that the browser, if overwhelmed by the processing of the outcome of a poll request, delays the next poll request (but we have no control on what the browser actually chooses to delay).
    This would avoid that the updates queue up on the client: they would try to queue up on the Server, which, however, can conflate them.
    We are ok even if the updates are queued up in client and process it in sequence, but we need to handle the browser close event.

    How is to be coded at both client and LS side to handle the delay at client side?


    Quote Originally Posted by DarioCrivelli
    If the next request is delayed too long, the Server will have discarded the Session and will get a "sync error".
    The client tries heuristically to measure its own processing delay and may request the Server to delay the Session discarding. Your setting of <max_polling_millis> is correct, because it avoids that the Server refuses to obey a client delay request which is too long.
    However, the client heuristic may be underestimating the delay.

    May we check your Server log taken during a polling run with 120 market watch details?
    You should set the priority of the LightstreamerLogger.requests.polling logger to INFO.
    I will be sending you the Server log files as early as possible.

    Quote Originally Posted by DarioCrivelli
    If you see the CPU usage steadily at 50%, it may be that only half of the available processors can be used by the browser; hence, this would still represent a bottleneck.
    You could still try removing all your callbacks from the NonVisualTables and see if the client CPU usage is still at 50%.
    We are using Firefox for testing purpose. But it allows more than 50% for Firefox and it goes 52% or 56% for this case but in an average of 50%.

    Can you please let me know what you mean by callbacks and how to clear it at client side?

 

 

Similar Threads

  1. Sync Errors
    By wwatts in forum Client APIs
    Replies: 1
    Last Post: February 20th, 2012, 09:14 AM
  2. Sync Errors
    By colmfield in forum Client APIs
    Replies: 2
    Last Post: September 22nd, 2010, 09:06 AM
  3. web client is not updating , no errors in server console
    By kishorekkk in forum Adapter APIs
    Replies: 1
    Last Post: April 10th, 2009, 08:33 AM
  4. StockListDemo (sync on different windows)
    By CitiMan in forum General
    Replies: 4
    Last Post: November 21st, 2006, 11:14 AM

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 01:15 AM.