Originally posted by rhochmuth One thing that we noticed is that the ObjectNotExistException is not thrown when using oneways which makes sense in hind-sight, but wasn't obvious at first.
Of course, this means that a oneway invocation is unreliable: it may never be sent (for example, because of a network failure) or it may not be accepted in the server (for example, because the target object does not exist). If anything goes wrong, the client-side application code does not receive any notification of the failure; the only errors that are reported to the client are local errors that occur on the client side during call invocation (such as failure to establish a connection, for example).
I'm not sure, it has been a while, but I don't believe that ice_ping() was throwing an exception when a oneway was used too.
What we've done in our application to test basic connectivity is to run a scrubber thread that tests connectivity at some time threshold using ice_ping(). If an exception is thrown we then clean-up the session.
When the connection was lost we were able to see that there were low-level socket exceptions that Ice was getting, but we were unable to get notification of.
Originally posted by level It's better that the ice(communicator) can tell me the proxy is in a state of unconnection ,on ice(communicator)'s initiative.
Instead of by call ice_ping() in my specially codes .
Originally posted by level I just care the ice_ping()'s efficiency.I consider the ice_ping() is equal to the DOS command ping.exe?
I am afraid of the 10000 or more client call ice_ping() that the sever can not do respond.
And if you use soket , the Closesocket function will tell you the unconnetion now?
Originally posted by rhochmuth We use oneways for many of our invocations mainly for performance. We have a p2p application in that both ends are clients and servers. I'll call one end the Receiver and the other end the Sender which is the terminology we use.
The Receiver invokes requestUpdate(). Then the Sender does a series of putUpdates() and finally an endUpdate(). Then the Receiver initiates another requestUpdate().The main point,here is that the Sender only does something in response to a Receiver request.
So if the Receiver is killed I believe what we observed was a Sender waiting for a new request. We would never see the ConnectionLost exception since there never was another method invocation, such as putUpdate(), on the Sender side.
I'm a little hazy on what happened to the socket exceptions in the Ice run time. I thought Ice caught them and did not propogate them up the call stack, but I might be mistaken. The other possiblity, is that they were propogated, but they weren't in a good location for us to use.
So that was the first reason for using and ice_ping(). Our Sender allocates a lot of memory per Receiver and we didn't want to keep this around when the Receiver was killed. A Ice invocation never occured on the Sender side in this case because it needed to be initiated by the Receiver.
The scrubber thread that performed ice_pings at 1-5 sec intervals that I mentioned earlier seemed like a good way to test whether the Receiver was alive.
The second reason was that since we use oneways the ObejctNotFound exception was not thrown. So in this case the Sender could be invoking putUpdate() in a Receiver that was still alive, but the ObjectAdapter had been desroyed. A twoway ice_ping() created the exception.