Results 1 to 6 of 6
  1. #1
    Join Date
    Apr 2010
    San Francisco

    Unable to connect to server from Cordova Ionic application

    Here is a summary of the issue:

    Weve built a native application using the Ionic framework which uses Cordova to wrap a web application into a native binary. Were using the LightStreamer Web Client (JavaScript) version 6.1.4. When attempting to connect to non-production servers the connection works fine and streaming proceeds as expected. When attempting to connect to our production servers the connection consistently times out with no errors or response from the server.

    Also, when running the code in a desktop browser the connection succeeds as expected, the issue is only when running natively on the phone.

    Below is the code were using to connect, you can see a few lines commented out where we tried changing the timeout and streaming methods.

    Lightstreamer.LightstreamerClient.setLoggerProvide r(new DebugLogProvider());
    var lsClient = this.lsClient = new Lightstreamer.LightstreamerClient( , this.config.adapter);
    onStatusChange: function(status) {

    onServerError: function(errorCode, errorMessage) {
    console.log('LS Error! Code: ' + errorCode);
    console.log('LS Error! Message: ' + errorMessage);

    lsClient.connectionOptions.setCookieHandlingRequir ed(true);
    //lsClient.connectionOptions.setConnectTimeout(10000 );
    //lsClient.connectionOptions.setForcedTransport('HTT P-POLLING')

    From the server side, this is all we see in the logs (Lightstreamer Server 5.1.1 build 1623.2):

    03-Oct-17 15:36:45,649|DEBUG|LightstreamerLogger.connections |NIO READ SELECTOR 1 |Reread HTTP connection on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,649|DEBUG| tp|SERVER POOLED THREAD 1 |Parsing request:
    GET /lightstreamer/create_session.js?LS_phase=705&LS_cause=timeout.2. 0&LS_polling=true&LS_polling_millis=0&LS_idle_mill is=0&LS_client_version=6.1&LS_adapter_set=JustAnsw er&LS_eng=s0& HTTP/1.1
    Accept: */*
    Accept-Language: en-us
    Connection: keep-alive
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Mobile/14G60

    on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating KEEPALIVE - no result configured
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.connections |SERVER POOLED THREAD 1 |Processing push request:
    /lightstreamer/create_session.js on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,650|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 1 |Serving request: /lightstreamer/create_session.js?LS_phase=705&LS_cause=timeout.2. 0&LS_polling=true&LS_polling_millis=0&LS_idle_mill is=0&LS_client_version=6.1&LS_adapter_set=JustAnsw er&LS_eng=s0& on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating use_compression - no result configured
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating use_http_11 - result from base rule: true
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating use_http_11 - result from base rule: true
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating USE_CACHE_HEADERS - no result configured
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating content_length - result from base rule: 500000
    03-Oct-17 15:36:45,650|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating max_streaming_millis - no result configured
    03-Oct-17 15:36:45,651|DEBUG|LightstreamerLogger.requests |SERVER POOLED THREAD 1 |evaluating KEEPALIVE - no result configured
    03-Oct-17 15:36:45,653|DEBUG|LightstreamerLogger.pump |SERVER POOLED THREAD 1 |Pump for session Sb5b49d2131c8bcabT3645652 added
    03-Oct-17 15:36:45,653|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 1 |Starting new session: Sb5b49d2131c8bcabT3645652 on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,654|INFO |LightstreamerLogger.connections |SERVER POOLED THREAD 1 |Reused HTTP connection on "Lightstreamer HTTP Server" from
    03-Oct-17 15:36:45,687|INFO |LightstreamerLogger.requests |FOR PUMPS PARKING DESTROYER|Closed session Sf4dde7f2328a790aT3625678 with internal cause code: 39 (Timeout).
    03-Oct-17 15:36:45,688|DEBUG|LightstreamerLogger.pump |FOR PUMPS PARKING DESTROYER|Pump for session Sf4dde7f2328a790aT3625678 removed

  2. #2
    Join Date
    Jul 2006
    The log shows the start of a session and, in the last part, a different session that times out while waiting for a rebind.
    This means that the session requests are accepted, but perhaps the client can't see the answers and can only retry.
    Please attach a longer log, covering at least 10 seconds, where we can see a full cycle from a client attempt to the next.

    Can you also show the log that you have collected on the client side for the same period?
    I see that you have defined a custom LoggerProvider. Ensure that it logs on all categories at DEBUG level, for instance with something like:
    this.addLoggerAppender(new ConsoleAppender("DEBUG", "*"));

    If we clarify how the problem is seen by Lightstreamer, we can then try to understand the causes.
    Since I see that you need to set setCookieHandlingRequired(true); is it possible that in the context of the native app the cookies are not handled as expected? This can only be ascertained by sniffing at network level.

  3. #3
    Join Date
    Apr 2010
    San Francisco

    Log files

    Attached both server and client log files in

    Attached Files Attached Files

  4. #4
    Join Date
    Jul 2006
    Hello Dan,
    Unfortunately, the problem seems widespread.
    The client tries various techniques to reach the Server, but all of them seem to be unavailable, each one for a different reason.

    The main hurdle is that normal XHR requests seem not available to our library.
    This is the usual way the client performs the initial request to open a new session.
    In your case, the client has to resort to a jsonp request, but then it seems that it cannot see the Server response.
    Usually, the jsonp technique works with any user-agent, but probably your app poses additional restrictions.

    To resume:
    1. In your environment some transports are not available to the library.
      It is possible that the limitation is in our library and that it needs an explicit support for this environment, since it cannot be recognized as a browser.
      Your requirement of cookie handling worsens the situation by posing additional constraints.
      Can you confirm that cookie handling is needed?
      BTW, when you test with the non-production environment, is setCookieHandlingRequired(true) still invoked?
      It would be interesting to perform a test in which you can remove this setting.
    2. The use of jsonp fails.
      Do you set restrictions like "Content-Security-Policy"?
      Do you have anything equivalent to the browser console where you can check if errors due to disallowed access are found in the responses?
      Moreover, is it possible for you to use a more recent Web SDK?
      This would make the investigation easier. However, this would also require the use of a more recent Server.

  5. #5
    Join Date
    Apr 2010
    San Francisco
    RE: Cookie Handling.
    Cookie handling is not required when we are bypassing the load balancer (as we are in this case). Disabling cookie handling seems to get things going but weve run into issues in the past where having cookie handling disabled caused connection and synch issues. So far Im not seeing these when testing the app.

    We do have access to a browser console. The connections to create_session.js work fine but I do not see any other requests (I do see those requests when looking at successful connections).

    Unfortunately we cannot try a newer version of the web SDK because it throws compatibility errors with our version of LightStreamer. We are currently using the most recent version supported by our server.

    I guess the open question now is, why does cookie handling work in non-production environments?

    For some context, attached is a log (nonProdLog.txt) with debug enabled in an environment that works:
    This is with Cookie Handling enabled in the lower environment.
    Attached Files Attached Files

  6. #6
    Join Date
    Jul 2006
    By comparing the two logs, we can see the root difference.
    After the first occurrence of "Verify if a connection class is appropriate", the following line is: "This class is good" in the successful case, whereas it is: "Cookies on request are required, this class can't guarantee that cookies will be actually sent" in the failed case.
    In the first case, the library issues a normal XmlHttpRequest; on the other hand, after the latter message, the library tries to contact the Server in a different way, but it turns out to fail.

    Note that you cannot see the messages, because you must have regenerated the library by omitting the LogMessages class to make it smaller. You could see the messages by using a full version of the library.

    What causes LS library to issue the second message is the combination of two factors:
    1. setCookieHandlingRequired(true) has been issued;
    2. the running environment doesn't appear to be a browser.

    In the successful case, at least one of the two restricting conditions doesn't hold.
    My assumption is that the running environment was the same in the two experiments;
    hence, the difference is that in the successful one setCookieHandlingRequired(true) was not issued.
    Do you confirm?

    Actually, all the above is independent of the cookie handling setting in your Load Balancer, which comes into play only at a later stage.
    With Lightstreamer, you have to ensure session stickiness, hence, if you opt for doing this through the cookies, you have no choice but to enable cookie handling and to invoke setCookieHandlingRequired(true).
    Hence, the problem lies in our library.

    I am still struggling to understand the exact conditions of your various tests.
    Each test is characterized at least by the following aspects:
    1. browser vs native app;
    2. presence or absence of a Load Balancer;
    3. cookie handling configured on the load balancer;
    4. setCookieHandlingRequired(true) invoked;

    Could you please resume?



Similar Threads

  1. Replies: 9
    Last Post: May 6th, 2015, 03:02 PM
  2. Replies: 12
    Last Post: August 12th, 2013, 01:52 PM
  3. unable to setup HTTP server
    By jdepp in forum General
    Replies: 0
    Last Post: January 2nd, 2013, 04:43 PM
  4. connect Light streamer and j2EE web application
    By pradeepgamage in forum Adapter SDKs
    Replies: 7
    Last Post: May 17th, 2012, 10:21 AM
  5. Replies: 2
    Last Post: August 22nd, 2011, 09:25 AM


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 12:12 PM.