Results 1 to 5 of 5
  1. #1
    Member
    Join Date
    Sep 2006
    Location
    Oakland
    Posts
    13

    Arrow Multiple connection warning alerts from Firefox

    With the latest client I am seeing occasional warning alerts popped up on Firefox that say something like:

    "Warning: there is probably another web application connected to the same Lightstreamer Server within this browser instance. That could prevent the current application from connecting to the Server. Please close the other application to unblock the current one."

    After clicking on that alert it is replaced with another that says almost the same thing but prefixed by an error code of some sort (maybe an obfuscated code location) and "ER changeStatus". After click on that alert there are no more but the streaming does not connect.

    So far I have only been able to reproduce this if I open multiple browser windows (not tabs) to our streaming site.

    I can understand there is probably some underlying limitation of Firefox that causes this - maybe a maximum number of connections by default (5?), but as far as I know I did everything possible to tell the web client library to not popup alerts so I'm confused that we are stilling getting alerts.

    From our on engine ready handler we have set:

    • objEngine.context.setDebugAlertsOnClientError( false );
    • objEngine.context.setRemoteAlertsOnClientError( true );


    and set error handlers for:

    • objEngine.onClientError
    • objEngine.onServerError
    • objEngine.onServerDeny


    and we also did the same on the lsPage.context when initializing the push page...

    So:

    • what's the scoop on the warnings (do the happen with IE too?)
    • how can we stop them and any other alerts appearing so we can handle them in our own application specific way?

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    HTTP specification and browser implementations force a maximum number of concurrent connections to the same host (HTTP specification prescribes 2, browser implementations are usually looser). This means that letting a user open multiple instances of the same Lightstreamer application (that connects to the same LS host) will saturate the browser's connection pool, resulting in th eimpossibility to run the latest instance and blocking new subscriptions and unsubscriptions in the previous instances.

    To prevent that, Lightstreamer implements a client-side mechanism that works in the following way:
    If an application cannot connect to LS Server AND at least another instance of that same application is opened in the same browser space (another tab or another window that shares the same process), then a warning is raised to the user, explaining they should close one instance.

    That warning is very important and cannot be disabled. Setting all the setDebugAlertsOnClientError(false) will avoid the duplication of the alert, but one alert, directed to the final user, will remain, because that's part of the framework logic.

    But notice that you have control over the behavior of the creation of a new Engine when a similar one already exists. See the onSimilarEngineFound parameter in createEngine(). You can decide to prohibit any further instantiation of the same application or to share the same Engine aming multiple instances. In both the cases that warning would never appear.

  3. #3
    Member
    Join Date
    Sep 2006
    Location
    Oakland
    Posts
    13
    Thank you for the explanation Alex. I was not necessarily looking to circumvent any such restriction, just have control over the text and placement of the error message - in general we consider a popup alert refering to "Lightstreamer" (which the end user may or may not have any knowledge of) is less than friendly. Feeding the error through the normal reporting callbacks already in existence seems preferable - and you can still refuse to start the engine as now.

    I will go investigate the alternate engine creation strategies you pointed out, I'd only just my code converted to the loadEngineMinimal method, now I notice it is deprecated!

    It is not clear to me what all the consequences of supporting sharing an engine across windows are, especially if the original push page that loaded it is closed. It makes sense for frame based apps, but if multiple browser tabs or windows are open - I'm just not sure.

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Quote Originally Posted by Waddy
    Thank you for the explanation Alex. I was not necessarily looking to circumvent any such restriction, just have control over the text and placement of the error message - in general we consider a popup alert refering to "Lightstreamer" (which the end user may or may not have any knowledge of) is less than friendly. Feeding the error through the normal reporting callbacks already in existence seems preferable - and you can still refuse to start the engine as now.
    Waddy, your considerations make sense. We promoted that alert to bypass any customization, to be sure it was not lost, but we'll probable introduce a way to customize the text or block it in a future release (quite soon).

    Quote Originally Posted by Waddy
    I will go investigate the alternate engine creation strategies you pointed out, I'd only just my code converted to the loadEngineMinimal method, now I notice it is deprecated!
    Yep, more clear and rational methods were introduced with Web Client 4.2: createEngine() and seekEngine().

    Quote Originally Posted by Waddy
    It is not clear to me what all the consequences of supporting sharing an engine across windows are, especially if the original push page that loaded it is closed. It makes sense for frame based apps, but if multiple browser tabs or windows are open - I'm just not sure.
    In that case, when the Master Push-Page is closed, all the pages stop pushing. But when a new Master Push-Page is created all the existing pages automatically attach to it. In a future relase of Lightstreamer, the automatic migration of the Master Push-Page will be implemented, that is: if the Master Push-Page is closed, an existing Push-Page is eelcted and becomes the new Master Push-Page automatically.

  5. #5
    Power Member
    Join Date
    Jul 2006
    Location
    Cesano Maderno, Italy
    Posts
    784

    onClientAlert released

    Hi All,

    following Waddy's advices we've added a new callback to both PushPage and LightstreamerEngine objects called onClientAlert.

    The new callback differs from the onClientError (1 2) callback in the message's purpose. While onClientError's messages targets the developer to warn him about possible problems, the onClientAlert's messages notify the final user on any critical conditions, related to its environment, that prevent the application from working.

    The default implementation shows an alert so that the behavior is kept the same as the previous versions of the web client. To stop the alerts substitute the default callback with an empty function is enough.

    Check these links for details:
    http://www.lightstreamer.com/docs/cl...#onClientAlert
    http://www.lightstreamer.com/docs/cl...#onClientAlert

 

 

Similar Threads

  1. IE script warning
    By jonasby1 in forum Client APIs
    Replies: 3
    Last Post: July 27th, 2011, 10:58 AM
  2. Replies: 1
    Last Post: March 25th, 2010, 10:04 AM
  3. Replies: 5
    Last Post: February 24th, 2009, 11:42 AM
  4. Replies: 2
    Last Post: March 5th, 2008, 07:29 AM
  5. Deprecation warning in the LiteralBasedProvider
    By jsharpe in forum Client APIs
    Replies: 1
    Last Post: April 19th, 2007, 10:24 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 06:24 AM.