Archived
Glacier Router and different adapter ids using the same identity
Looking at the code, it seems like the glacier2 routing table is built on identity only (Glacier2::RoutingTable::add). In our system, we use many well known identities that live on different icegridnodes, using different adapter ids (like myfactory@adapter1, myfactory@adapter2 etc.).
Is there any way to make Glacier2 include the adapter id/endpoint of a servant when making routing decisions?
Example code (this is stripped down from a real world application):
#include <Ice/Ice.h> #include <Glacier2/Glacier2.h> #include <My.h> int main(int argc, char** argv) { auto communicator = Ice::initialize(argc, argv); Ice::RouterPrx r = communicator->getDefaultRouter(); auto neoRouter = Glacier2::RouterPrx::checkedCast(r); neoRouter->createSession("", ""); { // Block A auto factory = My::MyFactoryPrx::checkedCast( communicator->stringToProxy("MyFactory@MyService0")); std::cout << factory->ice_toString() << std::endl; auto o = factory->getObjectById(1234); std::cout << o->ice_toString() << std::endl; } { // Block B auto factory = My::MyFactoryPrx::checkedCast( communicator->stringToProxy("MyFactory@MyService1")); std::cout << factory->ice_toString() << std::endl; auto o = factory->getObjectById(1234); std::cout << o->ice_toString() << std::endl; } neoRouter->destroySession(); communicator->destroy(); }
My.ice contains a very basic factory that returns a factored object, something like this:
module My { interface MyObject { //... }; interface MyFactory { MyObject* getObjectById(long id); } }
The server implements getObjectById in a straightforward way:
MyObjectPrx MyFactory::getObjectById(Ice::Long id, const Ice::Current& current) { return current.adapter->createProxy({std::to_string(id), "MyObject"}); }
MyService0 and MyService1 are adapters that run on two separate icegridnodes in iceboxes, on two separate servers.
Now, when running the example code from above, I would expect to see the following output:
MyFactory -t -e 1.1 @ MyService0 MyObject/1234 -t -e 1.1 @ MyService0 MyFactory -t -e 1.1 @ MyService1 MyObject/1234 -t -e 1.1 @ MyService1
Instead I see:
MyFactory -t -e 1.1 @ MyService0 MyObject/1234 -t -e 1.1 @ MyService0 MyFactory -t -e 1.1 @ MyService1 MyObject/1234 -t -e 1.1 @ MyService0 <-- wait, what?
When reversing Block A and Block B, the output is:
MyFactory -t -e 1.1 @ MyService1 MyObject/1234 -t -e 1.1 @ MyService1 MyFactory -t -e 1.1 @ MyService0 MyObject/1234 -t -e 1.1 @ MyService1 <-- wait, what?
So Glacier2 always talks to the first factory resolved, due to the identity that was cached in the routing table.
Comments
-
Hi,
It's not possible for Glacier2 to check for the adapter ID for the routing. At the protocol level, an Ice invocation doesn't include the full proxy (with either adapter ID or endpoint), it only includes the identity so Glacier2 has no way to figure out for which Ice object the request is supposed to be forwarded.
You should use unique identities for the factories if you need to be able to talk with the 2 factories from the client.
See also https://doc.zeroc.com/display/Ice36/Terminology#Terminology-IceObjects
Cheers,
Benoit.0 -
Thanks for the answer, that's what I suspected.
It might make sense to add explicit wording about this to Glacier's documentation, having your calls all go to whatever you happened to use first can produce quite surprising results.
0 -
These are places where this kind of information would be useful:
https://doc.zeroc.com/display/Ice36/How+Glacier2+Works
https://doc.zeroc.com/display/Ice36/Getting+Started+with+Glacier2
https://doc.zeroc.com/display/Ice36/IceGrid+and+Glacier2+Integration
https://doc.zeroc.com/display/Ice36/Securing+a+Glacier2+Router#SecuringaGlacier2Router-Glacier2RoutingTableAnd especially here:
https://doc.zeroc.com/display/Doc/Teach+Yourself+Glacier2+in+10+Minutes , where it says:Servers do not require any source code changes in order to work with Glacier2.
It could be described in terms of "when you're using Glacier2, make sure that all your object identities are unique" - even though, it could also be described as a guaranteed feature, which could be taken advantage of by clients.
0