Streaming issue when porting Javascript Client API 4.0 to 6.0

[DarioCrivelli]

The log reports a couple of WARN messages, but they are not errors and should not cause problems.
What happens is that your Data Adapter issues "update" or "smartUpdate" calls for some item, setting the "snapshot" flag also when the update is not the first one for the item.
This should be unrelated with your current problems.

In order to better compare the cases, please send us longer log snippets, starting before you ask for the page and covering at least 10 seconds.

By the way, your last log line reports "Lightstreamer/4.0.1 build 1513.1.3", whereas you said you were using the Colosseo (5.0) Server in both cases and that the only difference was the version of the JavaScript client library; may you please clarify?
Note that the JavaScript client library 4.0 is really old; can you confirm you are using this version, by looking at the included build.number file?

[huunghia]

Hi Dario Crivelli,

First of all, sorry for giving some wrong information. The client version I used before is version 5.0, not 4.0 as mentioned. And yes, the log I posted before is also with wrong server package (ie. 4.0).

Back to the issue, I attached the 3 logs: 1 with client version 5.0 on Jboss, 1 with client version 6.0 on jboss and the final one is the log when I run demo apps without jboss (3 of them are with server 5.0).

Checking the log of client version 5.0, I found that it seems that there is still "LS_polling=true". However, because the data is returned fast, that's why I had the feeling that it's in streaming mode. Comparing to the client version 6.0 on jboss, the retry in streaming-sense mechanism caused the latency in data return.

Hence, my question is now:
- Why deploying in jboss, there is no streaming (even I deployed the demo app client in jboss)?

Thanks in advance for your reply.

Nghia Pham

[DarioCrivelli]

Nghia Pham, sorry for adding a roundtrip, but for a full comparison of the cases we would also like to see a log of the StockListDemo with client library 6 deployed on JBoss, where you say it encounters the same issues as your application.

For now, the main difference between the two scenarios with your application (that is, with library 5.0 or 6.0) is that in the 5.0 case a common subdomain is set (namely testing.com), whereas in the 6.0 case it is not.
In fact, since 6.0, access from client pages to Lightstreamer Server no longer requires that a common subdomain is declared, provided that a proper configuration of cross site access has been provided.
Although the cross site access configuration must be correct (otherwise you wouldn't see the updates at all), it may impact on the streaming behavior in a few cases.
Does your client page issue "setCookieHandlingRequired(true)"?

Even if not, please try adding a common subdomain declaration to your client page, to see if anything changes. Note that with client library 6.0 there isn't a "setDomain" method anymore; you should just issue document.domain='testing.com'; early in your page. Obviously, the hostnames should be used consistently in the test.
By the way, what browser have you used for these testcases?

As a side note, I see that your logs are overwhelmed by the "Unexpected snapshot event for MERGE item ..." messages.
Although, as I said, this is not an issue, please check your calls to "update" or "smartUpdate" and ensure that the snapshot flag is set to false on any invocation that is used to forward real time updates; if in doubt, try setting it to false always.

[huunghia]

Thanks for your guide, Dario. We have just resumed the project as another project is with high priority.

Attachment is the log of StockListDemo with client library 6 deployed on Jboss and you can see that the it ran in polling mode. We tested on Safari.

We will try to follow your guide and feedback to you soon.

[DarioCrivelli]

The log seems incomplete; can you confirm that all you see in the log is what you sent us?
In this case, may you please retry the test and collect the log after setting the LightstreamerLogger.requests.polling logger at INFO level?

Until then, we cannot infer, from this log, that the session shown was in polling;
the LS_polling=true text that you see in the log has only a temporary scope and it is also used in streaming sessions.

May you please specify the version of Safari in use?

We wait for more feedback. In particular, please try the test by adding the domain setting in your app for javascript library version 5, as explained in my previous post.

[QuyenNguyen]

Dear Dario

On behalf of Nghia, I would like to continue the thread. We already added domain setting and tried again on Fire Fox and Safari (version 3.2.2). Please refer to attached logs of the 2 cases.
In Safari case, we notice that the session is not established at the first call, and have to force rebind several times.

Serving request: /lightstreamer/STREAMING_IN_PROGRESS?LS_session=S3fe4dab291897687 T0935312&LS_phase=8804&LS_cause=ws.notgood&LS_content_length=500000&LS_container=lsc&LS_eng= 468& on "Lightstreamer HTTP Server" from 192.168.1.93:10485

Hope this log can help you to figure out the problem.
Thanks
Quyen