How to restart a RfcServer after broken connection? (NCo 3.0.2)

[Former Member]

Hi,

I implemented a RfcServer which works fine so far. But if the connection breaks down due to network problems it stays in a unusable state and it seems the NCo does not reconnect automatically. What I do now is to stop the server if its state is Broken or Invalid:

if (server.Monitor.State == RfcServerState.Broken || server.Monitor.State == RfcServerState.Invalid) {
    server.Shutdown(false);
}

It is then restarted automatically after a few seconds:

if (server.Monitor.State == RfcServerState.Stopped) {
    server.Start();
}

This does work, the server changes its state to Stopped and a little later to Starting. But then, before it ever reaches "Running" an exception is thrown, kills the whole application and generates these entrys in the Application eventlog:

.NET Runtime version 2.0.50727.3603 - Schwerwiegender Fehler im Ausführungsmodul (000006427F44AE16) (80131506). (English translation "Fatal Execution Engine Error")

Faulting application myApp.exe, version 1.0.4164.17769, stamp 4ddf6643, faulting module mscorwks.dll, version 2.0.50727.3603, stamp 4a7cb0b3, debug? 0, fault address 0x00000000002c65c8.

The application is running as service (x64) for .net 3.5 SP1 on Windows 2003 R2 SP2. Any ideas? How to renew the registration with the SAP system?

[Former Member]

Hi,

I'm struggling with the same problem. I tried the approach you mention in your post but in my case the server.montor.state does not even change (stays on running).

Then I tried to capture the communication exception in the rfcservererror event and shutdown/start from within this event. The problem is there is no easy way of knowing when the network comes back (otherwise the start fails...).

So basically I did not yet find an elegant solution neither, but I think there should be one. This is really needed for building erro-proof RFCServer functionality and in NCO-2 it was possible so ...

I'm working with .net3.5/connector3.0.2/windows xp/32 bit and I did not experience the exception you describe, which could also depend on how it's coded.

(If you care you can always send me a small codesnippet and I'll try it on my side to see if I get the same error in a different environment...)

Best regards,

Marnik

Edited by: Marnik Overbergh on Jun 24, 2011 6:32 PM

[Former Member]

UPDATE :

Had some contact with SAP-OSS and they confirm that no extra coding is required in order for the NCO to reconnect. This seems to be standard functionality offered by the NCO. However they also said that there might be a little problem in some cases and they are now investigating further...

to be continued....

[Former Member]

SAP finally acknowledged this being a bug. This should be solved in NCO 3.0.3.

[Former Member]

Hello Marnik,

thanks for your updates. Just yesterday we updated to NCO 3.0.3. This night there was an RfcCommunicationException "Connection with cpicHandle = 57 and conversationID = closed by gateway.". Afterwards the server state changed from running to stopping,then from stopping to stopped. In the next few minutes no state change occurred and our own logic restarted the rfc server: State changed from Starting > Broken, Broken > Starting, Starting > Broken. Then the process was killed as before with a .NET runtime exception "... faulting module mscorwks.dll, version 2.0.50727.3603, stamp 4a7cb0b3, debug? 0, fault address 0x00000000002c65c8."

Should the NCO reconnect automatically even if the server state is stopped? I guess not, this is why I try to start the server again programmatically. Will keep on trying to find a solution...

Best regards,

Mathias

[Former Member]

Hi Mathias,

After the bugfix of SAP I can assure you that the RFCServer does reconnect. In fact you have to do nothing at all. Indeed the server will change to states stopping->stopped. I personally have simulated multiple kinds of connetion errors going from removing the connection in the sap gateway to actually physically breaking the connection...it did recover in all situations.

By the way are you sure you implemented note 1332022 which is a prerequisite for good functioning.

Of course it is always possible you discovered a bug in the connector.

What could narrow down the problem is by activating the tracelevel to value 3. In the resulting tracelog you should be able to see what the connector really does in more detail.

Keep us posted...

Regards,

Marnik