-
November 12th, 2010, 06:45 PM
#1
Proper way to "shudown" a Data Adpater
Hello all,
Our Data Adapters are implemented as Window Services. We are noticing that when we shutdown the service (i.e., from the SCM issue a Stop command) that the Lightstreamer log is reporting an error (We are using the robust data adapter)
<ERROR> Got fatal error from the inner Proxy Data Adapter...
Unexpected end of reply stream reached.
In our Service::OnStop method we execute the Close method (DataProviderServicer).
As part of initializing our service we open TCP sockets and connect the streams the NotifyStream,ReplyStream and RequestStream. Do we need to first close these streams?
What is the best way to "shutdown" a data adapter such that we don't get error logged.
Thanks in advance
Peter
-
November 15th, 2010, 10:56 AM
#2
Closing a Remote Data Adapter currently connected to LS Server is always considered a problem that is worth notifying with emphasis on the log, even when a Robust Proxy Data Adapter is in place.
You can initiate a controlled closure by invoking the "Failure" method from the Remote Data Adapter before starting the shutdown operation.
This causes a custom, hence suitable, error message to be shown on the Server side.
Note that invoking "Failure" may cause the Server to close the sockets first, which, in turn, may require the Remote Server to shutdown; you should ensure that the two requests for shutdown don't interfere.
-
November 15th, 2010, 03:47 PM
#3
More Questions
Dario,
Thansks for the reply.
What is the intended perpose of DataProviderServer.Close() method? i.e., why would a Data Adapter invoke this method?
When you say, "initiate a controlled closure by invoking the "Failure" method from the Remote Data Adapter before starting the shutdown operation." Are you refering to raising an exception? i.e., from the Data Adapter invoke
ItemEventListener.Failure? What exception? I suspect a custom exception ShutdownException?
What does the kernel do when it receives an exception?
You've indicated "Note that invoking "Failure" may cause the Server to close the sockets first, which, in turn, may require the Remote Server to shutdown; you should ensure that the two requests for shutdown don't interfere."
I suspect server here means the lightstreamer kernel. What do you mean by 'Remove Server to shutdown?" Are you refering to a Data Adapter that initiated the failure sequence?
Remember we have multiple Data Adapters (WinServices) connected to a single instance of lightstreamer and we want to shutdown one of these Data Adapter.
-
November 16th, 2010, 09:42 AM
#4
Just as a reminder, in Lightstreamer terms, the Remote Server is the process which creates a "DataProviderServer" instance, which, in turn, contains an instance of the Remote Data Provider.
Originally Posted by
PeterHiross
What is the intended perpose of DataProviderServer.Close() method? i.e., why would a Data Adapter invoke this method?
The "Close" method closes the streams and the threads devoted to the management of a Remote Data Provider instance.
It's invocation is not mandatory when the whole Remote Server process is about to close. However, the process lifecycle is controlled by your own code and you may want to shutdown a Remote Data Provider and then setup a new one, through the creation of a new "DataProviderServer" instance; in that case, you should invoke "Close" on the first instance.
Originally Posted by
PeterHiross
When you say, "initiate a controlled closure by invoking the "Failure" method from the Remote Data Adapter before starting the shutdown operation." Are you refering to raising an exception? i.e., from the Data Adapter invoke
ItemEventListener.Failure? What exception? I suspect a custom exception ShutdownException?
What does the kernel do when it receives an exception?
Yes, I referred to "ItemEventListener.Failure".
Through that method, we just enforce the convention that the failure of a Remote Data Provider is associated to a raised exception. You can pass any custom exception.
The exception will just be logged by LS in its own logging categories. With a Remote Adapter, the exception can also be sent to the Server in order to be logged there, but, actually, only the associated message is sent.
Originally Posted by
PeterHiross
You've indicated "Note that invoking "Failure" may cause the Server to close the sockets first, which, in turn, may require the Remote Server to shutdown; you should ensure that the two requests for shutdown don't interfere."
I suspect server here means the lightstreamer kernel. What do you mean by 'Remove Server to shutdown?" Are you refering to a Data Adapter that initiated the failure sequence?
Remember we have multiple Data Adapters (WinServices) connected to a single instance of lightstreamer and we want to shutdown one of these Data Adapter.
The "Failure" notification is managed by the Proxy Adapter running on the Server.
Only the simple "NetworkedDataProvider" forwards the "Failure" call to the Kernel, which in turn closes, because it is no longer able to ensure the consistency of the data (the clients will handle the case and try connecting to a different Server instance).
The "RobustNetworkedDataProvider", which is your case, does not cause the Server to close and it is the right choice when multiple Remote Data Adapters are in place. However, it causes the sockets towards your Remote Server to close.
What I meant in my previous post is that your Remote Server should invoke "Failure" first, then initiate a shutdown and possibly invoke "Close", which closes the sockets.
But the invocation of "Failure" will eventually cause the Proxy Adapter to close the sockets on its side.
You don't know who will close the sockets first. If the Proxy Adapter closes first, you will get an invocation to "handleIOException" on the "ExceptionHandler" associated to the "DataProviderServer".
Hence, you have to code "handleIOException" appropriately; the default implementation just calls "Exit" and this may not be suitable for your case.
Similar Threads
-
By hofmanna in forum Client SDKs
Replies: 3
Last Post: February 18th, 2010, 11:14 PM
-
By coyote7000 in forum Client SDKs
Replies: 3
Last Post: April 9th, 2009, 10:38 AM
-
By Alessandro in forum Adapter SDKs
Replies: 3
Last Post: May 30th, 2008, 01:49 PM
-
By Alessandro in forum Adapter SDKs
Replies: 0
Last Post: February 13th, 2008, 10:12 AM
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 11:09 AM.
Bookmarks