IcePack server registration madness

[Mobiwan]

Hi there!

I've been struggling with the IcePack manual server registration for two days now and I'm no longer sure if this is due to incompetence (most likely) - documentation on that issue is, errr, challenging, to say the least.

So, here's the problem. I want do do indirect binding between a client and a collection of similar objects distributed in a network. The server registers with

      LoadFetcher* theFetcher=new LoadFetcher();
      IceUtil::ThreadControl tc=theFetcher->start();

      Ice::ObjectAdapterPtr adapter = communicator()->createObjectAdapter("AgentAdapter");

      Ice::ObjectPtr object = new AgentI(*theFetcher);

      Ice::ObjectPrx objPrx = adapter->add(object, Ice::stringToIdentity(IceUtil::generateUUID()));

      IcePack::AdminPrx admin = IcePack::AdminPrx::checkedCast(communicator()->stringToProxy("IcePack/Admin"));
      admin->addObjectWithType(objPrx, object->ice_id());

      cout << "Press Ctrl-C to terminate." << endl;
      adapter->activate();

The client (in its simplest form, just to show the issue) does this:

     
      ic = Ice::initializeWithProperties(argc, argv, properties);

      Ice::ObjectPrx base = ic->stringToProxy(argv[1]);
      CpuMonitor::AgentPrx agent = CpuMonitor::AgentPrx::checkedCast(base);
      
      cout << "CPU Load for agent is " << agent->fetchCpuLoad() << endl;

When I register the first server and then fetch its identity via IcePackAdmin, everything works like a charm:

bash$ direct-client 10A5509D-819D-4371-970D-C01105D5284D
Contacting CPU Load server...
[ Location: retrieved endpoints from locator, adding to locator table
adapter =
endpoints = tcp -h 192.168.1.1 -p 12000 ]
[ Location: retrieved endpoints from locator, adding to locator table
adapter = AgentAdapter
endpoints = tcp -h 192.168.1.1 -p 9593 ]
CPU Load for agent is 0.99
bash$

But when I register a second server, the whole machinery seems to get out of sync. Ignoring which of the two IDs I use as direct-client argument, the output is either the load of the second server or the following:

Contacting CPU Load server...
[ Location: retrieved endpoints from locator, adding to locator table
adapter =
endpoints = tcp -h 192.168.1.1 -p 12000 ]
[ Location: retrieved endpoints from locator, adding to locator table
adapter = AgentAdapter
endpoints = tcp -h 192.168.1.1 -p 9593 ]
Outgoing.cpp:348: Ice::ObjectNotExistException:
object does not exist
identity: 280E2AA5-96C6-4C81-948A-7AC679B50CBF
facet:
operation: ice_isA

Do it another one, two or three times and you're back at the second server's load, just as if IcePack has a bookkeeping problem ?!

Anyone an idea?

Cheers,
Mobi.

[marc]

Please see this thread regarding our support policy:

http://www.zeroc.com/vbulletin/showthread.php?t=1697

[Mobiwan]

Please see this thread regarding our support policy:

http://www.zeroc.com/vbulletin/showthread.php?t=1697

Hmmmm.... I actually can't see the link between my company association and my IcePack problem, but if you feel you can't give hints without it, here's my sig.

Mobi.

[matthew]

I'm sorry but its not really clear how you are trying to do the distribution with your example below, or what the problem you are running into exactly is. Did you read my connections articles on IcePack? It goes through a step by step example of how to setup a chat service with IcePack.

[benoit]

I suspect that you have configured the adapter of each server to use the same adapter id (which is configured with the <adapter name>.AdapterId property). Each adapter should have a distinct adapter id. If that's not the problem, we would need to know a bit more about what you're trying to do and the configuration of your client and servers.

Benoit.

[Mobiwan]

I'm sorry but its not really clear how you are trying to do the distribution with your example below, or what the problem you are running into exactly is. Did you read my connections articles on IcePack? It goes through a step by step example of how to setup a chat service with IcePack.

Mat,

thanks for your reply. The point is that I actually don't actively distribute using IcePack but rather register existing Ice objects in a more traditional naming service registration approach. The approach should be visible in the code snippet:

Server side:
------------
- create the object adapter
- initialize the object adapter
- connect to icepackregistry admin interface
- register object proxy with type

Client side:
----------
- fetch object identitiy [ done manually using icepackadmin ]
- cast object identity to object reference
- call object

In the 'real' client, I connect to the icepackregistry query interface, fetch a sequence of all references with appropriate type and iterate over each of them. But as the problem is visible with the minimalistic approach, I sticked to it for the sake of simplicity. ;-)

Does that give you an idea of what I'm trying to do?

Cheers,
Mobi.

[Mobiwan]

I suspect that you have configured the adapter of each server to use the same adapter id (which is configured with the <adapter name>.AdapterId property). Each adapter should have a distinct adapter id.

Benoit.

Okay. That's indeed the case as they all initialize using the same config property file. But how can that do harm? They each run in their own process and register with IcePack using a unique object identity and IP/Port combination. Isn't that enough to have the client find the right destination?

Mobi.

[benoit]

The proxy that you register with the registry is "indirect" (see the IcePack chapter in the manual for more information on direct and indirect binding). It looks like the following:

"10A5509D-819D-4371-970D-C01105D5284D @ AgentAdapter"

So when your client invokes on the identity-only proxy, the locator returns the proxy "10A5509D-819D-4371-970D-C01105D5284D @ AgentAdapter" to your client, and your client query the locator again to get the endoints of the adapter "AgentAdapter". And in your case, this returns the endpoints of the last activated "AgentAdapter" adapter.

You need to set different adapter ids for each object adapter. Or, you might actually not need to set it at all if you only want to use the locator to resolve this given object (if you don't set the adapter id you will register a "direct proxy" that contains the endpoints of the adapter).

Benoit.

[Mobiwan]

The proxy that you register with the registry is "indirect" (see the IcePack chapter in the manual for more information on direct and indirect binding). It looks like the following:

"10A5509D-819D-4371-970D-C01105D5284D @ AgentAdapter"

So when your client invokes on the identity-only proxy, the locator returns the proxy "10A5509D-819D-4371-970D-C01105D5284D @ AgentAdapter" to your client, and your client query the locator again to get the endoints of the adapter "AgentAdapter". And in your case, this returns the endpoints of the last activated "AgentAdapter" adapter.

Okay, that makes sense. I had thought into that direction, but discarded that point because I (incorrectly) expected the IP/Port pair that must be hidden in the registration entry somewhere would make it unique.

So, the "@ AgentAdapter" part is caused by the AdapterId property and not by the object adapter creation parameter? I had thought so.

Cheers,
Mobi.

[benoit]

Correct. The object adapter creation parameter is the name of the adapter and the adapter id of the object adapter is configured with the property <adapter name>.AdapterId.

Benoit.

[Mobiwan]

Okay, thanks for the clarification.

Cheers,
Mobi.

PS: By the way, have you noticed the typo on your web site? You've announced the november issue with date of '10-03-2005' which would have been a little early... ;-)

[marc]

PS: By the way, have you noticed the typo on your web site? You've announced the november issue with date of '10-03-2005' which would have been a little early... ;-)

Oops... it is fixed now..

[Mobiwan]

I suspect that you have configured the adapter of each server to use the same adapter id (which is configured with the <adapter name>.AdapterId property). Each adapter should have a distinct adapter id. If that's not the problem, we would need to know a bit more about what you're trying to do and the configuration of your client and servers.

Benoit.

I reworked the config file this weekend and it started working instantly. :-)

Cheers,
Mobi.