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:
- browser vs native app;
- presence or absence of a Load Balancer;
- cookie handling configured on the load balancer;
- setCookieHandlingRequired(true) invoked;
Could you please resume?
