-
April 2nd, 2007, 05:14 PM
#1
Gracefully disconnect standalone .NET adapters
Is there a way to gracefully disconnect standalone .NET adapters when a LS server is stopped or fails?
We developed a standard alone .NET adapter to connect to LS and everything works as expected. The problem comes in when the LS server process has to stop (or fails), it terminates the .NET adapter process as well. It is as if the DotNetAdapter_N2.dll calls Environment.Exit() (or End statement in VB) when a remoting error occurs, resulting in the entire process being terminated.
Some background: The standalone .NET component we are developing retrieves states, pushes data and has other functionality that services not just to LS but to other components as well. Therefore if DotNetAdapter_N2.dll terminates the entire process upon remoting failure we can not use it within our process.
-
April 3rd, 2007, 10:06 AM
#2
Hi
Indeed, the .NET Remote Server offers a very limited interface from this point of view.
However, the forthcoming update of our distribution is going to overcome this specific limitation.
In any case, in order to get the control of the Remote Server process, you need to run the process through your own Main and instantiate an object of type Lightstreamer.DotNet.Server.DataProviderServer (and/or MetadataProviderServer), as explained in chapter 1.7 in DOCS-SDKs\sdk_adapter_dotnet\doc\DotNet Adapters.pdf
At the moment, this object does not support a listener for failure exceptions, but, as anticipated, in the next release it will, allowing you to override the default "Exit()" action.
Dario
-
April 3rd, 2007, 02:21 PM
#3
Hi Dario,
Thanks a stack for the reply it really helped! A few more questions:
1) How long before the expected update. We are in evaluation period and might be able to wait for the update.
2) If we can’t wait, what is the alternative? (We are thinking implementing our own ARI)
3) Does this behavior occur for the Java component as well? (Again we are in evaluation and could consider using Java instead of .NET for this specific component)
-
April 4th, 2007, 09:24 AM
#4
Hi
The next distribution update is expected within a couple of weeks.
In case you prefer to implement your own ARI, we recommend you to try keeping the Java component (i.e. the proxy adapter) and implement the protocol defined in
DOCS-SDKs\sdk_adapter_remoting_infrastructure\doc\ARI Protocol.pdf
in your own remote component.
However, as you suspected, the Java component has the same behaviour as the remote component, with respect to failure management. In synthesis, there is no recovery from problems in the communication between the proxy and the remote component.
In fact, in most cases, losing even a single update on the Data Adapter prevents the Adapter from honouring the interface contract with Lightstreamer Server.
So, whenever the connection is lost, the proxy Adapter makes the whole Server close, so as to leave to the clients all recovery decisions (assuming that a different Server is available in the cluster).
Note that, while on the Remote Adapter side there may be custom code to be preserved from a process close (as in your case), on the Server side, where the Proxy Adapter is running, this is not the case, unless other adapters are running. Only in the latter case (i.e. when other adapters are running), the Proxy Adapter behaviour may be unacceptable.
Only by coding your own Data Adapter in Java you can implement all the recovery strategies that your specific environment allows.
Dario
-
May 24th, 2007, 11:11 AM
#5
Hi Daro, does this apply the other way around as well then? I run the LS server in a windows service process, and connect via TCP from another process/computer.
When the latter process ends, the LS server (win service) ends too, even if I ran the Close() method on the "DataProviderServer" and the metaprovider before exiting the process. Is this an expected behaviour? I mean, it could be other .NET adapters connected to the LS server. If this is not intended, can you reconnect to the proxies on the LS?
brgds
Robert
-
May 25th, 2007, 10:18 AM
#6
Hi Robert,
yes, at the moment there is no recovery for interruptions in the event flow. The Server is just closed.
However, this limitation applies to the Proxy Adapter, which is a basic adapter for the management of remote .NET based feeds and which reacts to interruptions in the event flow by invoking a failure on the Server.
A sophisticated adapter could manage an interruption in the event flow and restore the flow in some way, or, maybe, send some meta-information to the clients.
If your system is based on several external event flows and you need to preserve working ones upon interruption of other ones, then our basic remoting infrastructure may be too limited.
Since a single connection to Lightstreamer Server can only specify a single Data Adapter, could using different Server instances for different adapters be a workaround?
Dario
-
May 25th, 2007, 12:16 PM
#7
Right. Thanks.
So I guess one have to set up several phsyical server boxes to do so. At least to be able to run on the same port. Am I right?
brgds
Robert
-
May 28th, 2007, 01:02 PM
#8
it is right in logical terms; you need to distinguish different servers by different addresses, as you probably wouldn't want to distinguish them by different ports.
In physical terms, I think that various approaches are available to achieve this, but I prefer not to speculate on this.
Dario
-
September 6th, 2007, 03:54 PM
#9
![Quote](images/styles/AestheticaGreen/misc/quote_icon.png)
Originally Posted by
DarioCrivelli
Only by coding your own Data Adapter in Java you can implement all the recovery strategies that your specific environment allows.
Dario
Do you mean coding your own PROXY Data Adapter in Java to run on the Lightstreamer server? That is, use a custom proxy adapter in place of the stock one supplied with the server-side software?
-
September 10th, 2007, 09:24 AM
#10
Yes.
Upon a crash of the Remote Server, a full recovery by the Proxy Adapter would require:
- finding a new Remote Server as soon as possible;
- resubmitting all current subscriptions to the new Remote Server;
- asking the new Remote Server for the snapshots related to the subscription requests occurred while no Remote Server was attached;
but also:
- asking the new Remote Server for all the updates occurred while no Remote Server was attached;
- managing the case in which no new Remote Server can be found after a reasonable time.
Some of these operations are very application-dependent.
Anyway, if forcing a client-side recovery after Remote Server unavailability is not acceptable, our simple remotization framework is of little help and a full messaging middleware should rather be used in order to feed Lightstreamer Server. This would require coding your own Data Adapter also on the java side.
On the other hand, if your main concern is to prevent Lightstreamer Server from exiting in order to preserve other adapters installed, then you may find it acceptable to recover the Remote Server crash by just reconnecting and resubscribing to a new Remote Server and losing all the events occurred in the meantime.
As this is a custom decision that would make the Data Adapter not honouring the interface to Lightstreamer Server, a custom Proxy Data Adapter would again be needed to implement it.
Dario
Similar Threads
-
By sebandres in forum Client SDKs
Replies: 1
Last Post: May 4th, 2011, 09:26 AM
-
By LS_Developer in forum Adapter SDKs
Replies: 2
Last Post: April 19th, 2011, 11:03 AM
-
By sjohn in forum Adapter SDKs
Replies: 7
Last Post: February 18th, 2008, 08:50 AM
-
By wattsw in forum Adapter SDKs
Replies: 2
Last Post: November 13th, 2006, 05:12 PM
-
By cvs_fif in forum Adapter SDKs
Replies: 8
Last Post: September 25th, 2006, 02:36 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 10:19 PM.
Bookmarks