Home Help Center

Indirect Binding

Hello,

I am trying to get the Ice/hello demo to work with the IcePackRegistry and indirct binding. My configuration file is as follows:
Ice.Warn.Connections=1

Ice.ConnectionIdleTime=10

IceSSL.Trace.Security=0

Ice.Plugin.IceSSL=IceSSL:create
IceSSL.Client.CertPath=../../../certs
IceSSL.Client.Config=sslconfig.xml
IceSSL.Server.CertPath=../../../certs
IceSSL.Server.Config=sslconfig.xml

 
IcePack.Registry.Client.Endpoints=tcp -p 12000 -h 10.54.19.208	
IcePack.Registry.Server.Endpoints=tcp -p 12001 -h 10.54.19.208
IcePack.Registry.Admin.Endpoints=tcp -p 12002 -h 10.54.19.208
IcePack.Registry.Data=db
IcePack.Registry.DynamicRegistration=1
IcePack.Registry.Trace.ServerRegistry=2
IcePack.Registry.Trace.AdapterRegistry=2


Ice.Default.Locator=IcePack/Locator:tcp -p 12000 -h 10.54.19.208
The server, registry and (eventually) client will be reading from this file. I am modifying the source to add the object and adapter through the Admin proxy. Here is how I have modified the Ice/hello server to accomplish that:
int
run(int argc, char* argv[], const Ice::CommunicatorPtr& communicator)
{
    Ice::ObjectAdapterPtr adapter = 
       communicator->createObjectAdapterWithEndpoints("Hello", "tcp -h 10.54.19.208 -p 10000" );
    Ice::ObjectPtr object = new HelloI;
    Ice::ObjectPrx proxy =  adapter->add(object, Ice::stringToIdentity("hello"));
   IcePack::AdminPrx admin = IcePack::AdminPrx::checkedCast(communicator->stringToProxy("IcePack/Admin"));
   adapter->activate();
   std::cerr << "\n\nGot Here!!!\n\n";
   try
   {
      admin->addObject(proxy);
   }
   catch(const Ice::Exception& e)
   {
      std::cout << "Some error: " << e << std::endl;
   }
   std::cerr << "\n\nGot Here2!!!\n\n";
    communicator->waitForShutdown();
    return EXIT_SUCCESS;
}

Currently it crashes on the admin->addObject line. The exception is not being caught and it points to an error saying "Debug Assertion Failed" in dbgdel.cpp. The call stack reflects nothing in the local scope, only displaying remote windows dlls. How can I better catch this exception, and what could be causing it? Thank you.

Jennie

Comments

  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi Jennie,

    I can think of two things you should check:

    1. Make sure the admin variable is not nil. For example, assert(admin)

    2. Make sure you are compiling using consistent compiler flags. Usually when a debug assertion occurs, it's because the flags used to compile the application don't match that of the Ice libraries.

    Take care,
    - Mark
  • JennieJennie Member
    Thank You

    Mark,

    Thank you, you are a lifesaver. That took care of my crash. It's now working, at least in the local scope. Thanks again.

    Jennie
  • Hi !
    I need help ...

    I am using IceGrid and IceStorm and some servers which exchanged own proxys via icestorm messages and i have a problem: ObjectNotExistException

    Firstly i start 1st server and first instance of 2nd server. In this case no problem. Then i start second instance of 2nd server which transmit own proxys returned by adapter->add() to the 1st server via icestorm message(as in the first case).

    But when 1st server try to use proxys received from second instance of 2nd server the ObjectNotExistException occured. Both instances of 2nd server using the same name of object adapter and generate different identity of ice-object.

    What reasons can be ?

    Thanks.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Max,

    ObjectNotExistException means Ice could not find the target servant when trying to dispatch a request.

    Are your 2 servers supposed to be replica of each other, with a replica group that contains the object adapter of these 2 servers? If so, then you must make sure that any object created by one object adapter is also created (or automatically re-created) by the other.
    using the same name of object adapter

    That's always fine: an object adapter name is local to an Ice communicator, and allows this communicator to look up the configuration of this object adapter.

    Be careful not to mix-up object adapter names with object adapter IDs; the ID is used in indirect proxies, like 'myadapter' in [email protected]

    Best regards,
    Bernard
  • bernard wrote: »
    Be careful not to mix-up object adapter names with object adapter IDs; the ID is used in indirect proxies, like 'myadapter' in [email protected]

    Yes, i missed it, I thought different identites is enough. Now i generate adapter id programmatically and it's works.

    Thanks for help.
Sign In or Register to comment.