-
March 10th, 2013, 10:12 AM
#1
Streaming mode never works on the old HTML Client API v5.01
Hi guys,
We're using the following release of Lightstreamer: 4.0.3 Duomo 20120406.
After some performance tests we did on the website, we found out that the Lightstreamer is always working on HTTP-POLLING mode (always performs the fallback from streaming mode).
So I thought I should test the demo project of the StockListDemo that uses the same HTML client API (the old lsengine.js, lscommons.js, lspushpage.js). I was surprised to find out that even on the Demo project it always works on HTTP-POLLING mode (after few second of Stream-sensing). In order to make sure I don't have any machine-specific issues, I tried the .Net client demo that you provided (DotNetClientStockListDemo) and it works flawlessly on Streaming mode.
Needless to say that on the latest release of Lightstreamer (5.1.1 Colosseo 20130131) the very same Demo project (StockListDemo but with the new JavaScript API) works perfectly on Streaming mode (on the same machine, of course).
I have tested all of the above on several machines.
Is this a known issue?
Is there any fix for it already?
If there is no fix, the only way to use streaming is to upgrade to the latest release?
Please let me know what you think.
Thanks,
Lidan.
Last edited by lidanh; March 10th, 2013 at 01:16 PM.
-
March 11th, 2013, 11:04 AM
#2
Streaming should work with the version you're using; did it stop working at some point or are you developing a new application with it?
Please try this demo: http://www.lightstreamer.com/demo/_o...Demo_client_5/
Does it start in streaming or polling mode?
-
March 14th, 2013, 11:45 AM
#3
Hi,
It starts in polling mode.
It appears that our network is blocked for HTTP Streaming but not for WS Streaming.
This is why I'm able to stream data using the new version (that has WS Streaming) and not being able to stream data using the old version (that does not support WS Streaming).
Regarding the performance issues I'm having... The Stream-sensing mode takes about 4 seconds. Is there anyway to reduce this? Lots of our end-users cannot use HTTP-Streaming and it takes 4 seconds in average for the Lightstreamer to understand that.
Appreciate your prompt reply.
Thanks,
Lidan Hackmon.
-
March 15th, 2013, 10:31 AM
#4
On the new library you can use the public setConnectTimeout method to change the timeout.
On the old library that setting exists but as a private method; you can use it but it is not officially supported nor documented:
-
March 17th, 2013, 02:23 PM
#5
I will definitely try that.
Edit:
It works!
Is the default value 4 seconds like the new version?
Thanks,
Lidan.
Last edited by lidanh; March 17th, 2013 at 02:38 PM.
-
March 18th, 2013, 10:16 AM
#6
yes it is, the default is 4 seconds on the old lib too
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 06:06 AM.
Bookmarks