If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Streaming issue when porting Javascript Client API 4.0 to 6.0

Dear Lightstreamer experts,

I have developed an online trading application which is deployed into Jboss 4.0. The security information was developed based on JSP using Javascript client API 4.0 which received streaming data from Lightstreamer server (Colosseo 5.0). Everything worked fine with the Javascript client API 4.0 until I decided to port my Client pages from Javascript client API 4.0 to Javascript client 6.0. I followed the porting guide from Lightstreamer exactly. However, after porting the code, it seems that the new client page cannot connect to LS server in Streaming mode.

I tested with Safari and the status message shown that the connection is in Polling mode and of course, the data returned very slow. Then I switched to Firefox and sometimes, the connection can be in Streaming mode (sometimes it's not).

I tried to deploy demos application (stock list demo) to my Jboss server and the same issue occurred even this demo application is in normal streaming connection if deploying out of Jboss 4.0.

Thanks for your reply. Sorry that we cannot deploy the application out of Jboss. We can just run LS demos without Jboss only and I believe you can have the log at your side. Please note that your LS demos faced the same issue if I deployed them on the jboss 4.0.

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?

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)?

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.

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.

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.