Why web client keep receiving "<script>p();</script>"

chanro4

Hi,
I am new to Lightstreamer and I followed every step in the hello world tutorial to create my first page.
http://cometdaily.com/2008/02/12/%E2%80%9Chello-world%E2%80%9D-with-lightstreamer/

But when I used a tcp tracer to trace the traffic, I found that the web client keep receiving "<script>p();</script>". What is that? How can I avoid server to send this to web client?

<body onload="if (! clsd) { retry(); }">
<script>setPhase(8203);</script><script>start('Sad4dacee6e7da822T1357536', null, 2000, 50000);</script><script>s0(0.0,1.0,-1.0);</script><script>c(6,39,0);setWin(0,39);</script><script>z(0,1,"Hello","Fri Dec 10 09:13:57 GMT+08:00 2010","#");z(0,2,"#","#","#");</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>p();</script><script>y(30);</script><script>d(0,1,"World","Fri Dec 10 09:14:27 GMT+08:00 2010","");</script><script>p();</script><script>p();</script>

Regards,
Ronald

Alessandro Alinone

Hi Ronald,

These are keep-alive messages used to keep the connection active, so that intermediate firewalls and proxies do not decide to close it. By default, a keep-alive packet is sent every 2 seconds, when no actual data is flowing on the connection. You can increase such interval by changing the <max_still_millis> element in lightstreamer_conf.xml.

chanro4

Hi,
Thanks for the reply. I have two more questions on using Lightstreamer.

1) For the clustering support, the offical site has the following notice:
------------------------------
Multiple instances of Lightstreamer Server can be clustered through a Web load balancing appliance to guarantee load balancing and failover.
------------------------------
Does it means that we need a explicit load balancing tool to setup failover ourselves? Or Lightstreamer itself support failover via configuration?

2) For the snapshot of items, are they stored in the JVM instance of server? Is there any overflow rule that can be set to control the size of the total snapshot?

Thanks.

Regards,
Ronald

Dario Crivelli

Should a Server instance fail for any reason, the client libraries will try to recover by reconnecting towards the same address.
To allow that, you may have a new instance start immediately by acting at the Operating System level; we don't provide any ready-made script for this task.
On the other hand, a Load Balancer ensures that, at the time one Server instance fails, others are alive and can be reached immediately at the same address.

About the snapshots, I confirm that the current snapshots are stored in the JVM heap for all items for which isSnapshotAvailable returns true.
It is not possible to put limits on the memory needed for keeping the snapshots.
Only for items in DISTINCT mode, the getDistinctSnapshotLength callback sets the number of events kept on an item basis (this is not needed for MERGE mode, where only the latest state of each field is kept).
For items in COMMAND mode, on the other hand, the snapshot is made by all keys added and not deleted yet and it cannot be limited, as that would compromise data correctness.
Hovever, the snapshot size also grows with the number of fields and the field value size and all this only depends on the nature of the data.

If you can estimate the size needed to keep the various snapshots, you can put a limit on the overall number of subscribed items, by acting on the Metadata Adapter.

chanro4

Snapshot stores in JVM of server, so I will lose all the snapshot if I failover to the standby server?

And isn't it that if an item is unsubscribed from data adapter, all the snapshot of this item will be deleted?

Dario Crivelli

Yes, if the failover is to a Server instance which is initially idle, all the items have to be subscribed to again and no snapshot information is available within the Server.
Note that the Data Adapter, upon the subscribe call, has the opportunity to send to the Server kernel the current snapshot, if you have kept it somewhere in the system.

I confirm that upon unsubscribeall snapshot information is lost by the Server kernel; as said above, the Data Adapter could restore the snapshot at the next subscribe call.
Note that unsubscription only occurs when all the clients interested in the item have gone and that, in case of page refresh, the Server tries to keep the previous subscriptions for a few seconds, so that when the new page asks for the items they are still subscribed to.
You can force important items to never be unsubscribed from by using a custom, internal client, which requests them and stays alive forever.