Archived

This forum has been archived. Please start a new discussion on GitHub.

A problem about IceGrid's replicated servers

If two servers implement differenct interfaces, but they have the same identity(for example: thePrinter@theAdapter), what will happen if they register to IceRegistry ? Can IceRegistry reject the second server's registration ? The following is my demo code:

Printer.ice---
module Demo
{
interface PrinterA
{
void printStringA(string s);
};

interface PrinterB
{
void printStringB(string s);
};
};

ServerA.cpp----
class PrinterAI : public PrinterA {
public:
virtual void printString(const string & s,
const Ice::Current &);
};

int
main(int argc, char* argv[])
{
int status = 0;
Ice::CommunicatorPtr ic;
try {
ic = Ice::initialize(argc, argv);
Ice::ObjectAdapterPtr adapter
= ic->createObjectAdapterWithEndpoints("theAdapter", "default -p 10000");
Ice::ObjectPtr object = new PrinterAI;

//objectId: thePrinter@theAdapter - implementation the PrinterA interface
adapter->add(object,
Ice::stringToIdentity("thePrinter"));
adapter->activate();
ic->waitForShutdown();
} catch (const Ice::Exception & e) {
//...
}
}

ServerB.cpp---
class PrinterBI : public PrinterB {
public:
virtual void printString(const string & s,
const Ice::Current &);
};
//...

int
main(int argc, char* argv[])
{
int status = 0;
Ice::CommunicatorPtr ic;
try {
ic = Ice::initialize(argc, argv);
Ice::ObjectAdapterPtr adapter
= ic->createObjectAdapterWithEndpoints("theAdapter", "default -p 10001");
Ice::ObjectPtr object = new PrinterBI;

//objectId: thePrinter@theAdapter - implementation the PrinterB interface
adapter->add(object,
Ice::stringToIdentity("thePrinter"));
adapter->activate();
ic->waitForShutdown();
} catch (const Ice::Exception & e) {
//...
}
}

Comments

  • benoit
    benoit Rennes, France
    IceGrid isn't released yet :). I'll describe how IcePack currently handle this, IceGrid won't be different in this respect.

    At the object adapter level, IcePack will do the following:
    • If you're not using dynamic registration (i.e.: IcePack.Registry.DynamicRegistration=0) , the IcePack registry will prevent you from registering 2 object adapters with the same id. It will also prevent you from activating an object adapter with a given id if an adapter with the same id is already activated (assuming this adapter was registered explicitly with the registry).
    • If you're using dynamic registration (i.e.: IcePack.Registry.DynamicRegistration=1), IcePack won't prevent you from activating an object adapter with a given id twice.

    At the object level, there's nothing to prevent you from using the same identity for different objects. You have to ensure that your objects use a different identity. The only case where it makes sense to use the same identity is for a replicated object.

    Benoit.
  • benoit wrote:
    At the object level, there's nothing to prevent you from using the same identity for different objects. You have to ensure that your objects use a different identity. The only case where it makes sense to use the same identity is for a replicated object.

    Benoit.

    Thank you!

    Can IcePack restrict that differenct objects using the same identity must confirm to the same interface ? Maybe this is very useful!
  • benoit
    benoit Rennes, France
    Note that registering an object with the Ice object adapter won't automatically register it with the IcePack registry. To register it with the registry, you need to use the IcePack::Admin interface or the deployment descriptors.

    It would be possible to automatically register objects with the IcePack registry and add some checks at the time of the registration. However, this would add some overhead for applications which register many objects...

    It's probably better if you ensure at the application level that your objects use a unique identity, you can for example use UUIDs for this purpose.

    Benoit.