-
March 18th, 2012, 11:28 PM
#1
What is the best way to perform reconnection from client side?
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
-
March 20th, 2012, 09:16 AM
#2
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?
-
May 1st, 2012, 03:04 AM
#3
exception handling and bubbling
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
-
May 2nd, 2012, 10:33 AM
#4
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.
-
June 11th, 2012, 05:10 PM
#5
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?
-
June 13th, 2012, 08:26 AM
#6
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?
-
June 13th, 2012, 12:55 PM
#7
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.
-
June 14th, 2012, 08:35 AM
#8
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.
Similar Threads
-
By LS_Developer in forum Client SDKs
Replies: 1
Last Post: March 20th, 2012, 08:51 AM
-
By deltron0 in forum Client SDKs
Replies: 6
Last Post: September 15th, 2010, 08:33 AM
-
By pacesie in forum General
Replies: 1
Last Post: March 26th, 2008, 09:01 AM
-
By indrajit in forum Adapter SDKs
Replies: 1
Last Post: February 22nd, 2008, 08:39 AM
-
By deltron0 in forum Client SDKs
Replies: 2
Last Post: February 5th, 2008, 05:28 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 07:02 PM.
Bookmarks