Archived
This forum has been archived. Please start a new discussion on GitHub.
How to detect an invalid proxy?
ssergei
in Help Center
My question is, is there a way to detect if a proxy is bad, i.e. the server exited uncleanly, simply crashed? If a client tries to use proxy when server crashed the remote calls will never return. At least if you use an indirect proxy. I tried ice_ping() - it didn't return too.
Thanks,
Sergei.
Thanks,
Sergei.
0
Comments
-
If the server process crashes, then ice_ping() should return with an exception (usually ConnectFailedException or ConnectionLostExcpetion). I do not know why it doesn't return such an exception in your case. The only case I can think of is if the server host (not just the server process) crashes. In this case, it might either take a very long time until the TCP stack detects that the server is not reachable, or it might not detect it at all. Setting a timeout on the calling proxy is the best option to avoid this problem.
In any case, you should be able to get more information about what's going on by analyzing the network tracing output of the client (with Ice.Trace.Network=2).0 -
Thanks, Marc. No the server's host is ok. I think, it has something to do with an indirect proxy I use. The server registers an object with the registry and when server crashes, the object doesn't exist anymore but is still registered. When I remove the object from the registry manually, then ice_ping throws the "ObjectNotRegistered" exception.
Sergei.0 -
The output with trace.retry and trace.network:
Network: trying to establish tcp connection to <server's IP number>:1783
Retry: connection to endpoint failed, trying next endpoint
.\Network.cpp:536: Ice::ConnectionRefusedException:
connection refused: WSAECONNREFUSED ]
Retry: connection to cached endpoints failed
removing endpoints from cache and trying one more time
And again, this repeats endlessly.0 -
I was able to reproduce the problem. I believe this occurs only for indirect proxies containing only the identity of the object (let me know if that's not your case however). To work-around the problem for now, you could specify the adapter id in your proxy, i.e.: use 'identity@AdapterId' instead of just 'identity'.
We'll fix this bug ASAP and thanks again for the report!
Benoit.0
