riaanj
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. :eek:
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.
Dario Crivelli
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
riaanj
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)
Dario Crivelli
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
robert@cts.no
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
Dario Crivelli
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
robert@cts.no
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
Dario Crivelli
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
TonyRoberts
@DarioCrivelli, Wrote:
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?
Dario Crivelli
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
TonyRoberts
@DarioCrivelli, Wrote: Yes.
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
Right. If I want to do this then how to I go about doing it? I mean, is there some Java sourcecode supplied with Lightstreamer which I can use as the starting point to create custom Proxy Data Adaptor?
Dario Crivelli
Tony,
we didn't think of making the Proxy Adapter a reusable sample code
(though we don't obfuscate it).
However, we'll send you the current source code by email, after a short revision of the embedded comments.
TonyRoberts
@DarioCrivelli, Wrote: Tony,
However, we'll send you the current source code by email, after a short revision of the embedded comments.
OK, thanks
TonyRoberts
@TonyRoberts, Wrote: OK, thanks
How are we doing on getting this Adapter Proxy code to use?
Dario Crivelli
Tony,
we resent you the code a few days ago and we still haven't received the reception notification back. It seems that we can only communicate through this forum. Could you receive the code?
Dario
TonyRoberts
@DarioCrivelli, Wrote: Tony,
we resent you the code a few days ago and we still haven't received the reception notification back. It seems that we can only communicate through this forum. Could you receive the code?
Dario
No, not received yet.
I saw you private message to me yesterday and responded to it, three times I think :Smile_Ab: Have you seen those messages?
Dario Crivelli
I sent the private message on Monday and I haven't received any answer yet.
I'm not skilled with this forum tool, though.
Please find the Proxy Adapter source code at:
http://www.lightstreamer.com/temp/proxy_adapter_src.zip
Dario
TonyRoberts
Excellent, thanks, got it now.
TonyRoberts
@DarioCrivelli, Wrote: Tony,
However, we'll send you the current source code by email, after a short revision of the embedded comments.
OK, now I have the source, which JDK should I be using to build it?
TonyRoberts
Right, further to my earlier reply I just downloaded and installed the latest JDK from the Sun website. I then also had to download and install log4j from Apache.
Problem I now have is that the Java source for the Adaptor Proxy is importing things like
com.lightstreamer.interfaces.metadata.ItemEvent and I don't have the source or the .jar files for any of these classes. Looks to me like I need com.lightstreamer.interfaces.*