Hi Everyone,

I am having this issue with entirex .net wrapper. Whenever the rpc server crashes (gets hung for some reasons) and the client is trying to logon, the application gets hung because it’s not getting a response from the server. The code for the logon in my .net application is something like this:

broker = New Broker(strBrokerId, strUserId)
broker.logon(); <== the application gets hung here when rpc server is down.
service = New Service(broker, strServerId)
service.Timeout = Convert.ToUInt32(15)
rpclibObj = New SoftwareAG.EntireX.NETWrapper.Generated.MyLib.Rpclib(service)
…

In my java wrapper application, i have similar codes:

broker = New Broker(strBrokerId, strUserId);
broker.logon();
rpclibObj = New Rpclib(broker, serverid);
rpclibObj .setDefaultWaitTime(15S);

but don’t have the above problem because somehow there is a response returned to the application indicating that the server is down.

My question is how do I tell the application that it should only wait for 15 seconds for get a response from a broker. In other words, if it can’t logon to the broker in 15 seconds, then it should return program control to the application?

Thanks and Regards,
Paul

Hi Paul,

this sounds a bit strange. Are you sure that the application hungs at broker.logon() ? The logon() does not call the RPC Server …

What error do you get in case of Java ? It might be a good idea to switch on tracing to see what’s happening.

Rolf,

Thank you so much for your response.

Yes, when the server is clogged (when we brings it down, we saw error messages such as S1 0051 APSDIS0014-* Task group DEFAULT delete requested, waiting for 6 users ), I ran the .NET application in debug mode, I saw it hanging right at broker.logon without falling to the Catch statement. However, the Java application did and the control was returned to the application.

Best Regards,
Paul

Could you elaborate a bit on your environment? In particular, what RPC server and Broker are you using (version, platform, tools, etc)? The “APS” product prefix (assuming this is coming from a Software AG product) is associated with the SMARTS subproduct), so I’m curious as to what the problem is there.

The problem you are describing doesn’t give us the whole picture: a LOGON request goes the the Broker, not the RPC Server. If the Broker is down or you have a network problem reaching the Broker, then there are different timers to adjust than if the problem is in the communication with the RPC server itself. As Rolf says, a failed RPC server will not cause the LOGON to hang up.

For a .Net client, you could try setting the environment variable ETB_TIMEOUT to see if it helps with your specific problem.