https and java client

ManKeer

I have a java LS client and HTML 5 Ls client, both of them are connecting to LS server.

The LS server is located behind the load balancer, the LS server running under https protocol.

The problem that the HTML5 connects easily to the LS server, however, the java client doesn't reach the LS server at all...

What should I do in order to get the java client connected to the LS server.

Giuseppe Corti

Hi ManKeer,

The APIs of the Web and Java client libraries are very similar, so there should be no substantial differences in the connect operations between the two client applications.
Some preliminary checks that you could make are:
- make sure that the license running on the server correctly enable both client libraries, this can be verified in the server log in the initialization phases or in the "License" tab of the monitoring dashboard;
- if the server is behind a load balancer and you are using a Java client library below version 4.3.0 the default value for setEarlyWSOpenEnabled is different from the JavaScript lib; setting it to false could be critical in some scenarios.

If you are still having problems we will need some more information and also logs.
You should check that while the Java client is trying to connect the server log is not logging anything at all, and in this case enable client-side logging.

Regards,
Giuseppe

ManKeer

Hi Giuseppe,

I have used the setEarlyWSOpenEnabled two times, one with true and one with false, I have the client side logs for both case, however, the server side doesn't receive any connection request from the client.

The logs are ready just let me know how can I send u the logs.

Regards

Giuseppe Corti

Hi ManKeer,

In order to provide the Java client logs you can contact us at support@lightstreamer.com

Regards,
Giuseppe

ManKeer

Hi Giuseppe,

I have sent an email to lightstreamer support, the email contains two attached files, one when setEarlyWSOpenEnabled= true, and one when setEarlyWSOpenEnabled = false.

Regards

Giuseppe Corti

Hi ManKeer,

Thank you for the logs, we have checked them and first of all I want to clarify that the value for EarlyWSOpen seems completely irrelevant for the issue.
Indeed from the logs it is evident that every time the client lib tries to open a connection with the server, in order to send the create_session request, it immediately receives the error "Couldn't get a socket, try again".
So it would seem a connectivity problem between the device running the client and the Lightstreamer server. Please could you check by telnet or ping if the two machines can communicate? Maybe it's a DNS problem and the client can't resolve the host name?

Regards,
Giuseppe

ManKeer

Hi giuseppe,

I have asked this question again on the stackoverflow, I have got the following response "The observed behavior is not related to client and server versions, but to other context characteristics. For instance, one of the many possible causes could be that the needed root certificate is missing in the java environment. My suggestion is to write to Lightstreamer support forum, where you will have the opportunity to submit client and server logs."

Now, my application is distributed to the clients, does that imply that I need to import the certificate in my JAR file????

would you please clarify this point for me?

Giuseppe Corti Hi ManKeer,

Thank you for the logs, we have checked them and first of all I want to clarify that the value for EarlyWSOpen seems completely irrelevant for the issue.
Indeed from the logs it is evident that every time the client lib tries to open a connection with the server, in order to send the create_session request, it immediately receives the error "Couldn't get a socket, try again".
So it would seem a connectivity problem between the device running the client and the Lightstreamer server. Please could you check by telnet or ping if the two machines can communicate? Maybe it's a DNS problem and the client can't resolve the host name?

Regards,
Giuseppe

Giuseppe Corti

Hi ManKeer,

It seems to me that the actual cause of the problem has not yet been definitively determined.
But if it is really a refusal by the java client to accept the certificate (or a part relating to the chain of intermediaries) because of a missing certificate root in the jvm, yes a possible solution would be to provide the missing certificate with the client installation.

However, please consider that cases like this depend on a very unusual or extremely recent root certificate, and sometimes an update of the jvm is enough to solve the problem.

Regards,
Giuseppe

ManKeer

I have applied the code below, which loads the keystore that contains the required certificate, unfortunately not worked....

char[] keyStorePassword = "MYPASSWORD".toCharArray();
KeyStore ks = KeyStore.getInstance("JKS");
FileInputStream fis = new FileInputStream("MYKEYSTORE.jks");
ks.load(fis, keyStorePassword);
fis.close();

TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(/*"X509"*/TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(ks);
LightstreamerClient.setTrustManagerFactory(trustManagerFactory);

Giuseppe Corti

Hi ManKeer,

At this point, maybe the certificate hypothesis as cause of the issue is no longer valid.
However, it seems appropriate to me to have as much information as possible about the issue.

Please, could you provide us with a snippet of the server log (lightstreamer.log) of a test case that fails?
We can start with the factory configuration of the log; then based on the results we may ask you to move to more verbose levels.

Thank you,
Giuseppe

ManKeer

Dear Giuseppe,

I have sent an email for "support@lightstreamer.com", I have attached the required logs for you, my email was titled by "Al Jazira Capital Logs", however I have noticed the following and I don't know if it's a correct note or not:

* It seems that the java client connections come through bind_session and all of them rejected by network error.
* All HTML5 connections come through create_session and all of them are accepted.

Waiting your response.

Giuseppe Corti

Hi ManKeer,

Thank you for the server log.
Your considerations are absolutely correct, in fact several javascript sessions work perfectly; as you can see, following one of these, the correct flow would be:

- received the create_session request form the client;
- created the session id and returned to the client;
- received the bind_session from the client;
- start with the regular activities of the session (subscription request ...).

But for the Java Client there is no request to create_session at all. Only bind_session which all fail due to sync error.
This behavior is very strange, and may be due to two reasons:
- the create_sessions of the java client end up in a wrong server instance, this may be due either to a problem with the balancer or with a misconfiguration of the client;
- the client has very serious delays such that the create request and the subsequent bind exceed the life of the server. Actually this is very unlikely.
Can you check whether in front of the Lightstreamer server there is a balancer that sends the requests of the same client to two different instances?
Do javascript and java clients have the same network intermediaries to get to the server?

However, it might be useful to also have the client side log that we can match with that of the server.
Please in order to enable the client log you can add the following lines to your application:

SystemOutLogProvider prov = new SystemOutLogProvider();
LightstreamerClient.setLoggerProvider(prov);

You may also need to add to your project the dependencies 'com.lightstreamer:ls-log-adapter-java:1.0.1' and 'com.lightstreamer:java-system-out-log:1.0.2', which you can find on our public Maven repo.

Please let us know if you need any further clarifications.

Regards,
Giuseppe

ManKeer

Hi Giuseppe,

Thank you for your response and I appreciate your help.

I just want to ask what do you mean by "misconfiguration of the client", here is the client configuration:

myClient = new LightstreamerClient(LOAD_BALANCER_URL+":443", "STOCKLISTDEMO");
myClient.connectionDetails.setUser("MY_USER");
myClient.connectionDetails.setPassword("MY_PASSWORD");
myClient.connectionOptions.setEarlyWSOpenEnabled(true);
myClient.setLoggerProvider(new SystemOutLogProvider());

I will send you the client logs soon.

Regards

Giuseppe Corti Hi ManKeer,

Thank you for the server log.
Your considerations are absolutely correct, in fact several javascript sessions work perfectly; as you can see, following one of these, the correct flow would be:

- received the create_session request form the client;
- created the session id and returned to the client;
- received the bind_session from the client;
- start with the regular activities of the session (subscription request ...).

But for the Java Client there is no request to create_session at all. Only bind_session which all fail due to sync error.
This behavior is very strange, and may be due to two reasons:
- the create_sessions of the java client end up in a wrong server instance, this may be due either to a problem with the balancer or with a misconfiguration of the client;
- the client has very serious delays such that the create request and the subsequent bind exceed the life of the server. Actually this is very unlikely.
Can you check whether in front of the Lightstreamer server there is a balancer that sends the requests of the same client to two different instances?
Do javascript and java clients have the same network intermediaries to get to the server?

However, it might be useful to also have the client side log that we can match with that of the server.
Please in order to enable the client log you can add the following lines to your application:

SystemOutLogProvider prov = new SystemOutLogProvider();
LightstreamerClient.setLoggerProvider(prov);

You may also need to add to your project the dependencies 'com.lightstreamer:ls-log-adapter-java:1.0.1' and 'com.lightstreamer:java-system-out-log:1.0.2', which you can find on our public Maven repo.

Please let us know if you need any further clarifications.

Regards,
Giuseppe

Giuseppe Corti

Hi ManKeer,

I just mean to be sure that LOAD_BALANCER_URL is the proper url to target for the client.
But from the inspection of the snippet of your client code I would like to suggest to you to try to disable the earlyWSOpen, since this setting could be an impediment in some balancing scenarios (for example if <control_link_address> is configured on your server).

myClient.connectionOptions.setEarlyWSOpenEnabled(false);

Regards,
Giuseppe

ManKeer

Hi Giuseppe,

I have sent an email to "support@lightstreamer.com" from my email "m.ankeer@aljaziracapital.com.sa", I have attached the log file of the java client there.

Is it possible to join us in a zoom meeting at 4:00 PM KSA time.

Regards