LS_Developer
I have an LS client application which allow disconnection and reconnection to LS server. I would like know what is the right approach to achieve that. Should the app use the same LS_Client to re-open the connection or create a new LS_Client object instead?
Currently, my app is using the prior approach (using the same LS_Client object). However, sometime the app will get frozen when it try to reconnect. Any idea why the open connection call never get return?
Thanks
Dario Crivelli
The LSClient object enforces serialization on the OpenConnection and CloseConnection methods.
This means that if one OpenConnection is blocked, the block may propagate to any subsequent CloseConnection and OpenConnection that you invoke on different threads.
In this regard, using different instances of the LSClient object is better.
In fact, there is no important reason to suggest keeping the same object.
But note that connections blocked for any reason can keep other connection attempts blocked anyway, in case the client runtime keeps a small connection pool.
Can your case fall within the above scenarios?
If not, could you manage to get a full thread dump of the .NET client process while it is blocked?
sky.sanders@gmail.com
i am having trouble determining the best way to bubble exceptions (lightstreamer exceptions and explicitely thrown) from the table listener up to the client application.
am i missing a bubbling mechanism or is there an example of such an implementation?
thanks
Dario Crivelli
If you mean that you would like to receive table events also in a more general listener, I confirm there is no such mechanism in the .NET Client Library.
But please clarify your needs, so we can try to depict the nearest alternative.
sky.sanders@gmail.com
the need is to bubble exceptions from the table listener implementations that are passed in when a table is subscribed to.
consider if my table listener has trouble deserializing some data received from the server and throws an exception; must i really write an out of band mechanism to have access to those exceptions?
Dario Crivelli
I confirm that the exceptions thrown by the table listener are just caught, in order not to interrupt the operations, but then they are discarded.
Admittedly, this was taken from the java version of the library, where exceptions have to be declared and no exception is allowed to the listeners.
Did you expect, for instance, that an exception on the table listener would be notified in the ConnectionListener?
sky.sanders@gmail.com
the only expectation i have is that unhandled listener exceptions are not silently swallowed by the LSClient and/or Connection.
right now my only access, indirectly at that, to unhandled exceptions in a listener is by capturing and parsing the log.
but this does nothing for reacting to exceptions in program flow.
Dario Crivelli
Unfortunately, exceptions thrown by a listener are currently not even logged by the library.
They are not expected in any way.
Hence, your code is supposed to catch and process all exceptions before returning from any listener method.
We acknowledge that this leaves plenty of room for improvement in terms of library usability and will evaluate a possible extension for a future release.
