Opened 6 years ago

Closed 5 years ago

#11401 closed bug (no change required)

Lightstreamer regression in web+ - WebSocket broken

Reported by: AlienSoldier Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description Site using this don't populate with pushed data. I use a site using this for work and can't daily use fresh install to test daily, i can't linkmy working site because it is behind a password but they have a "stock quote" demo at the bottom of the page. When it work the data appear, when it don't an empty rectangle is show. On the site i use there is a progress status indicator like a sandglass that never end, data never appear but no error is ever reported.

I don't remember when it broke but it was working in hrev47207 (i think it also worked in august but i can't be sure as i don't update as often as i should).

Change History (7)

comment:1 by pulkomandy, 6 years ago

We have a WebSocket implementation now but it isn't working perfectly yet. I guess LightStreamer used some slower fallback method before and that did work.

comment:2 by AlienSoldier, 5 years ago

I contacted the developpers here is what they have to say:

" I confirm that if the websocket does not work the Lightstreamer JavaScript client library should automatically fall back to other technologies. It may be that the implementation of websocket of Haiku behaves in a completely unexpected way so that the algorithm can not fall back to the HTTP-Streaming or HTTP-polling.

If you have the possibility to act on the client code you should try to force a transport defferent from WebSocket, see here . In your case should be fine something like this:


Otherwise, you'd be able to disable websocket browser-side? (Something like the network.websocket.enabled flag in firefox) "

Perhaps it does not fall back now that the socket implentation is more advanced so it stay in limbo? If so and not really usable perhaps it would be better to revert it until more compliant (unless it can be usefull for some site in the current state).

comment:3 by AlienSoldier, 5 years ago

I continued talking with the company and it seem that they found a problem on their server side. The new version will be out in the comming week so i will test back and report if the problem is really closed.

comment:4 by pulkomandy, 5 years ago

Summary: Lightstreamer regression in web+Lightstreamer regression in web+ - WebSocket broken

comment:5 by Mone83, 5 years ago

[Disclaimer: I work for the company that makes Lightstreamer]

Hi, I had the time to test one of your nightly builds (namely 48869 gcc2 hybrid); what I noticed is that the issue is not related to websockets (they work fine) but to the Arguments object.

The arguments object can be obtained in two ways, one is deprecated[1], the other is not[2]. While I do not expect to find the deprecated form, I expect that if it is indeed available it should also be usable.

I attach a tiny test case for the issue:

function foo() {
  bar(arguments); //expects [object Arguments] prints [object Arguments]
  bar(arguments[0]) ///expects 1 prints 1
  bar(foo.arguments); //expects [object Arguments] prints [object Arguments] 
  bar(foo.arguments[0]) //expects 1 prints undefined

function bar(args) {


I'm linking the mdn documentation for convenience's sake [1] [2]

comment:6 by AlienSoldier, 5 years ago

I don't know the method it use in hrev48829 but i can see the data correctly now. I was not able to test for a while because the build upload link were not available. Perhaps it was fine before that build, i was just not able to test.

So i don't know about the socket, but as far as lightstreamer, i consider the problem closed for now.

comment:7 by waddlesplash, 5 years ago

Resolution: no change required
Status: newclosed

Thanks for the update!

Note: See TracTickets for help on using tickets.