Mone
The error on the bind_session is related to the <cross_domain_policy> configuration on the server: since the client was working before I suspect that the server is actually correctly configured and thus that error can't be explained.
Try upgrading the client lib to 6.1. I don't think there is anything that could solve the issue there though
Try keeping the client disconnected
Try reducing the size of the bind_session request by modifying the <content_length> element in the server configuration or by manually switching safari to polling. Given the situation this is currently my best bet.
I would take a look to a memory profile, but unfortunately that version of Safari does not yet have a memory profiler.
On my side I didn't reproduce the OOM but I got an unresponsive Safari after a night of DISCONNECTED:WILL-RETRY (I had the log enabled though, my bad).
I'll try to dig deeper, but it may take a while because I'm leaving for a short vacation.
HTH
kpturner
Mone
Try reducing the size of the bind_session request by modifying the <content_length> element in the server configuration or by manually switching safari to polling. Given the situation this is currently my best bet.
I think I need an idiots guide here :Smile_Ab:
Mone
Option 1 is to open the lightstreamer server configuration file and search for the <content_length> element, than, assuming you're on a test environment, reduce it to something much smaller (let's say 100 times smaller).
Option 2 means changing the client code by adding the following call:
[SYNTAX=JS]lightstreamerClientInstance.connectionsOptions.setForcedTransport("HTTP-POLLING");[/SYNTAX]
The effects of the two are somewhat simlar, number 1 making the streaming connection smaller (i.e.: when the content length is exhausted the client closes the current streaming connection and opens a new one) and number 2 making the streaming connection the smallest possible (each time something is received the connection is closed and a new one is opened).
kpturner
OK - so assuming I don't want to impact all the difference browsers connecting to the server, I need to use option 2 and condition the code based on the browser type?
Giuseppe Corti
Yes, you are right.
Option 1 is practicable if you could reserve a Lightstreamer test server to find out the Safari issue.
Nevertheless, please note that you may define a special case recognized by the user-agent supplied with the request in order to differentiate the behavior of the server. Please refer to the inline documentation of the <special_case> parameter.
kpturner
My preference was the javascript approach, so I will give the HTTP_POLLING option a try for Safari and see if it still crashes.
kpturner
I have just noticed that even without the javascript change, Safari is using HTTP-POLLING anyway. So I don't think that forcing it to use polling is going to fix my problem.
Mone
Hi kpturner,
I left my safari connected to
http://demos.lightstreamer.com/StockListDemo/ during the weekend and I got the OOM error.
Now that I can reproduce I'm going to try and find what's causing it.
I'll keep you posted
kpturner
OK thanks.........
Mone
Hi,
I have to leave safari going for two full days to reproduce the issue, hence the slow response here.
Anyway I found the issue:
what happens is that a certain point one of my array (that is used as a task queue) becomes unusable: calling push on it results on a OOM.
I manually tried to replace it with a new one and everything went back to normal.
I will probably introduce a work-around in the library by replacing the array from time to time (better not to wait for the OOM)
Mone
During this weekend I tested my workaround: looks like it's working.
I'm sending you a download link for the new library, let me know if this works for you too.
kpturner
OK - received and installed - thanks :Smile_Ab:
Will give it s couple of days.
kpturner
Seems fine now :Smile_Ab:
Mone
great, thanks for the feedback
