I have started logging these errors in a console (not the browser console but something in our app) with a time stamp and this is what happened:
So the out of memory errors started at 22:18 - which is NOT when the server is down. It is still active at this time - so I have given you a bum steer there. It then happens a few times more, then stops until I interact with the browser again at 09:00. Once our client disconnects overnight, it does not attempt to reconnect until user activity is detected (mousedown, keypress etc). So I got another "Out of memory" error when I attempted to reconnect the LS client. Notice the line number for the error in the morning is different.Code:An unexpected error has occurred at Mon, 10 Mar 2014 22:18:09 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 657 An unexpected error has occurred at Mon, 10 Mar 2014 22:18:14 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 657 An unexpected error has occurred at Mon, 10 Mar 2014 22:18:16 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 657 An unexpected error has occurred at Mon, 10 Mar 2014 22:18:51 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 657 An unexpected error has occurred at Mon, 10 Mar 2014 22:18:56 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 657 An unexpected error has occurred at Tue, 11 Mar 2014 09:00:08 GMT: 'Error: Out of memory' The url is 'http://rnsdev:9081/js/lightstreamer/lightstreamer.js?v=6.00.7517' The line number is 691
Looking at the memory usage for WebKit in the resource manager and it is nothing unusual at all.
The Safari Console shows is attached, reporting a problem with bind_session.js just before the "Out of memory" issue.
The browser itself is not behaving very well now I have this error condition. It is not even rendering properly.
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
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:
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).
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?
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.
My preference was the javascript approach, so I will give the HTTP_POLLING option a try for Safari and see if it still crashes.
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.
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
Bookmarks