Archived
This forum has been archived. Please start a new discussion on GitHub.
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:
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
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.208The 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
0
Comments
-
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,
- Mark0 -
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.
Jennie0 -
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.0 -
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 hello@myadapter.
Best regards,
Bernard0 -