Unable to connect to server from Cordova Ionic application
Here is a summary of the issue:
We’ve built a native application using the Ionic framework which uses Cordova to wrap a web application into a native binary. We’re 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 we’re 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.host , this.config.adapter);
lsClient.addListener({
onStatusChange: function(status) {
console.log(status);
}
});
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 10.40.1.27:55402
03-Oct-17 15:36:45,649|DEBUG|htstreamerLogger.connections.ht 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
Host: 192.168.54.123
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 10.40.1.27:55402
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 10.40.1.27:55402
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 10.40.1.27:55402
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 10.40.1.27:55402
03-Oct-17 15:36:45,654|INFO |LightstreamerLogger.connections |SERVER POOLED THREAD 1 |Reused HTTP connection on "Lightstreamer HTTP Server" from 10.40.1.27:55402
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
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.
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:
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.
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.
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 we’ve run into issues in the past where having cookie handling disabled caused connection and synch issues. So far I’m 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.
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:
setCookieHandlingRequired(true) has been issued;
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:
Bookmarks