How to handle ice exceptions correctly？

[free-wind-0]

As we all know, the ice communitor is a heavyweight object，when we call a method and an exception is caught, should we destroy it each time and recreate it? Is there a better way? I didn't find a better way to do it from the demo， my code looks like this：

// define general exception callback
auto exception_cb = [this,](std::exception_ptr eptr){
{ 
        this->ic->destroy();
        this->valid=false;
         ...
}

// invoke 
{
  if(!this->valid)
  {
     if(ic) ic->destroy();
      ...
      ic =  Ice::initialize();
      service = Ice::checkedCast<ServicePrx>(ic->stringToProxy("..."));
     ...
     this->valid = true;
  }
  
  try
  {
     invokeAsync(request, resp_cb, exception_cb );
  }
  catch( const Ice::Exception & e)
  {
     log(...);
     this->valid = false;
  }
}

[pepone]

Typically, you should initialize the communicator at the beginning of your application and destroy it when the application exits. However, you don't need to destroy the communicator if an exception occurs during an invocation.

[free-wind-0]

so what do I need to do after I catch the invocation exception? close the connection? Re-checkcast to get the new Prx? or just do business processing? I use icegrid

Can you provide generic exception handling methods？for using ice grid or directly connecting to ice server.

[bernardnormier]

As @pepone wrote, you should only create a single Communicator per application.

In particular, if you catch an Ice exception and this exception is something your application can tolerate, just continue. You should not recreate your Communicator. And you should not close any connection manually in your code either. Ice takes care of opening/closing connections for you. Just keep going.

[free-wind-0]

I guess this design is to solve the problem that some ice nodes cannot handle business normally, or the load is too high to respond in time, so it choose to destroy the ice communicator and obtain a other node from icegrid again (a link is established with a node, the next call, client does not to obtain other nodes by registry). If it is based on this consideration, I learned from icegrid document should use Ice. Default. LocatorCacheTimeout configuration, but if the cache timeout is not reached and an exception is received, how do I get other nodes from registry?

thank you for your reply. I will modify and adjust this design @bernardnormier @pepone

[bernardnormier]

but if the cache timeout is not reached and an exception is received, how do I get other nodes from registry?

The connection establishment and reuse logic is described here:
https://doc.zeroc.com/ice/3.7/client-server-features/connection-management/connection-establishment

In your situation, what happens depends on the number of factors:

• is this connection closed as a result of this exception?
• is your locator resolving adapter ID / well-known proxies by returning 1 or more endpoints?
• is your proxy configured to reuse its initial connection over-and-over?

The "best" scenario here is the connection is closed OR the proxy is configured to use a different connection for each invocation, and the locator returns multiple endpoints. In this situation, it's likely your next invocation will open (or reuse) a connection to another server.

On a side note, we reworked and simplified this logic in IceRPC, where everything is much more modular:

• the locator cache logic is in its own interceptor (the LocatorInterceptor)
• the connection caching/reuse logic is in the ConnectionCache class
• a proxy no longer "remembers" its connection - the reuse logic is in ConnectionCache, not in the proxy code

ConnectionCache always tries server addresses (the new name for endpoints) in order, while Communicator tries endpoints at random by default (see EndpointSelection).