Connection to server failing Closed HTTP connection with internal cause code: 10

[giuseppe.corti]

Hi baalbaki,

Thank you for the feedback.

But please let me stress out that we are well aware of the Log4Shell vulnerability but in short Lightstreamer is not affected.

The Lightstreamer Server has been using the logback library for its own logging since version 5.0. Logback is not affected by this vulnerability because it does not use the vulnerable log4j-core library.
Indeed the Lightstreamer Server comes with a few preinstalled demos, whose adapters use log4j for logging. These are the demos that populate the welcome page in a fresh installation of Lightstreamer.
But we don't expect that a public installation of Lightstreamer Server includes the demo Adapter Set and/or allows access to the demos. In the PRODUCTION_SECURITY_NOTES.TXT document that is included in the root folder of all Lightstreamer distributions, we have always recommended removing the preinstalled demos.
We had already upgraded our Lightstreamer distribution to version 2.17.0 but we also know that another minor problem was found shortly after and fixed with the version 2.17.1. I confirm that the next release will contain the update.

Obviously if you decide to use log4j2 in your adapters it is absolutely recommended to upgrade to the latest version (2.17.1).

Regards,
Giuseppe

[baalbaki]

Hello support.
whenever I shutdown the lightstreamer server in my simulator i get this callback ConnectionListener:: onFailure(PushConnException e) and after that onUnsubscrAll() from com.lightstreamer.ls_client.HandyTableListener i have which i guess its normal.
The issue happened with our real MD provider, we are connected to it we received this:
ConnectionListener: Connection stalled then ConnectionListener:: onFailure(PushServerException e):
In that case is it normal that this is not called: onUnsubscrAll() from com.lightstreamer.ls_client.HandyTableListener ?
Thanks

[giuseppe.corti]

Hi baalbaki,

It seems that the two environments have different network infrastructures or anyway with substantially different behavior when shutting down a Lightstreamer server.

In the first case, the client immediately detects the disconnection of the client session and correctly throws a PushConnException and signals the unsubscription of all active subscriptions.
In the second case, however, the client does not immediately detect the disconnection but the session simply becomes silent.
After the proper timeout the session goes into the Stalled state. Then once the PushServerException is received, that is considered a serious error.

In any case is the application that must take the necessary actions to create a new session (and new subscriptions).

Regards,
Giuseppe

[baalbaki]

Hi Giuseppe,
Can you let me know if this is true? if not, in which case the unsubscription of all active subscriptions is called?
1-If we receive a PushConnException, we will ALWAYS get a unsubscripton for all active subscription callback. true or false
2-If we receive a PushServerException, we will NEVER get a unsubscripton for all active subscription callback. true or false
Thanks
Ahmad

[DarioCrivelli]

Hello,
The interface contract is that every time the session is terminated and a onFailure notification is sent, the notifications of the termination of the involved subscriptions are also sent.
Hence 1 is true and 2 is false.
If you see anything different, it may be a bug.
Unfortunately, the library in use is very old (it was overridden by a better library in 2016 and abandoned in 2019), hence it may be difficult to find and fix a bug.
Anyway, the observed behavior may also be associated to something particular that happens in your case or to other differences between the two scenarios you are comparing.

If the lack of the notification causes problems, we can investigate deeper by taking some log.
The library logs through the JDK's java.util.logging support.
I have attached the sample logging configuration file that was provided with that SDK (with a .txt suffix added).
You can have the JDK configured with it by adding

-Djava.util.logging.config.file=logCfg.properties.txt

to the client command line.
If you can replicate the behavior with a minimal and short interaction, you can set all loggers to the FINEST level.
Then we can compare the two cases.

[baalbaki]

Thanks for the quick response Dario!