Sync errors in server log

Dario Crivelli

I mean that you should try detaching (i.e. not definig at all) the onItemUpdatecallback of your NonVisualTable ,
so that all streaming data are read by LS library but not processed at all;
then see if the CPU usage decreases
and, in that case, the Sync Error also disappear.
This test may not be feasible, as the overall page behavior may be altered; it depends on how your page actually works.

krishnamani

@krishnamani, Wrote:
I will be sending you the Server log files as early as possible.

Please find the attached server log of this case.

krishnamani

@DarioCrivelli, Wrote: I mean that you should try detaching (i.e. not definig at all) the onItemUpdatecallback of your NonVisualTable ,
so that all streaming data are read by LS library but not processed at all;
then see if the CPU usage decreases
and, in that case, the Sync Error also disappear.
This test may not be feasible, as the overall page behavior may be altered; it depends on how your page actually works.

Hi Dario Crivelli,

If we remove the callbacks of market watch NonVisualTable, then it takes 0 to 2% of CPU and Sync Error disappears, but this will totally turns off the actual requirement.

If you can tell us that what is the maximum time to be taken to process each market watch at client side, we will try to optimize and confirm if we can do it in required time and still receive such Sync Errors.

Regards,
Krishnamani

Dario Crivelli

The log shows several subsequent attempts to start streaming sessions, which cannot survive longer than a minute because of the sync errors.
It seems that your <session_timeout_millis> setting is of just a few seconds. With a greater valuer you could have avoided some sync errors, but you might have just postponed the problem. I also suppose that you kept this value low so as to speedup session closure when the browser is closed.

Anyway, this is consistent with what we already know, that is: the client is slow at processing the updates and eventually delays its rebind requests.
Note that we asked you something different: a log that shows an example with polling mode, that is, an example execution in which the client page explicitly issues changeStatus("POLLING")instead of changeStatus("STREAMING") .
If we have understood well, you get sync errors also in this case, despite the heuristic attempts by LS client library to handle elaboration delays.

The experiment without the callbacks shows that the elaboration of the updates accounts for most of the activity and the reading phase by LS library is not a bottleneck.
You may try to find some part in the custom code of your page that can be optimized strongly, but we cannot help you in this task.
We also cannot provide concrete usage requirements. In general, you should ensure that the average time the client takes to elaborate an update is less than the average time between two updates. This obviously depends on the browser, the OS and the hardware.

krishnamani

@DarioCrivelli, Wrote:
Anyway, this is consistent with what we already know, that is: the client is slow at processing the updates and eventually delays its rebind requests.
Note that we asked you something different: a log that shows an example with polling mode, that is, an example execution in which the client page explicitly issues changeStatus("POLLING")instead of changeStatus("STREAMING") .
If we have understood well, you get sync errors also in this case, despite the heuristic attempts by LS client library to handle elaboration delays.

Hi Alessandro & DarioCrivelli,

With reference to your previous replies and support mail refering the below link
http://www.lightstreamer.com/vb/showthread.php?t=683

I have implemented the same case earlier with small changes and removed the kill session call in time scheduler that caused sync error in both Streaming and Polling mode.

Again when tried keeping kill session in time scheduler the same code (including changes / handles i made) works without Sync Error.

Can you tell me why it is necessary or compulsory to have kill session, and how it works (As I don't find the kill session is being called at anytime in my code.)?

Thanks and Regards,
Krishnamani

Dario Crivelli

Sorry, but the description of your case has been spreading over many posts and several threads and now I find it difficult to understand the correct references implied when you write "the same case", "time scheduler", "Again", "the same code", "my code".
May you please provide more details?

krishnamani

@DarioCrivelli, Wrote: Sorry, but the description of your case has been spreading over many posts and several threads and now I find it difficult to understand the correct references implied when you write "the same case", "time scheduler", "Again", "the same code", "my code".
May you please provide more details?

Hi Dario,

Actually my case is to handle the Browser Close Event in Notify Session Close Event.

For that I referred thread under:
http://www.lightstreamer.com/vb/showthread.php?t=683

and tried to implement in similar way to handle it.
During Notify New Session, I added a thread that will maintain the session of the user. During Notify Session Close, if the session id matched with the session id maintained with user then send log out for the user.

But while implementing, I thought it is enough if we have put the user and session mapping in a Map and killsession in Timescheduler is not required and removed(as given in thread http://www.lightstreamer.com/vb/showthread.php?t=683).

At this implementation level, I have got Sync Error and I have posted the same in Forum.

But As Alessandro mentioned this again and again to refer same post http://www.lightstreamer.com/vb/showthread.php?t=683, I have used killsession in Timescheduler as mentioned in the site, and now I am not receiving any Sync Errors. And it is working fine.

Can you tell me why it is necessary or compulsory to have kill session, and how it works (As I don't find the kill session is being called at anytime in my code.)?

Dario Crivelli

As far as I know, your need is to allow at most one session for each user;
hence, your original goal was to "handle the Browser Close Event in Notify Session Close Event",
but, being that impractical, you agreed on a different policy, that is, forcing termination of a user session if the same user should start a new session from another page.

Sticking to the simplest case, i.e. that you are running a single Server instance, this means that your Metadata Adapter has to

keep track of the active sessions, by hooking session starting and termination in notifyNewSessionand notifySessionClose ;
detect, in notifyNewSession, when the user is opening a session S2 while another session S1 is currently active and, in that case, forcing termination of S1.

If you are in this simple single-instance case and you have followed the suggestions in thread http://www.lightstreamer.com/vb/showthread.php?t=683, point A), then you must be using the ConflictingSessionException technique; may you please confirm this?
In this case, I confirm that using the "kill session" mechanism is not needed;
it would be needed only if multiple Server instances were involved.

krishnamani

Hi Dario,

I am using single instance of server, and I followed to keep track of sessions created and detected session close and used it to identify browser close, when user has no active sessions.

but, for this, I used similar to sample code in, http://www.lightstreamer.com/vb/showthread.php?t=139&page=2#13.

I didnt use ConflictingSessionException as in Point A.

If I need to use that instead, can you please confirm me, if this is available in Lightstreamer Moderato version?

Regards,
Krishnamani

Dario Crivelli

Yes, ConflictingSessionException is available in all versions.

« Previous Page