Archived

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

IceGrid Adapter and Proxy Identites

I am having trouble matching (and understanding) identities and names in the ice interface as defined by the icegrid xml file. I was able to run the trivial client, but that uses config files and not the xml.

consider the following icebox service:

virtual void start(const ::std::string&name,
const ::Ice::CommunicatorPtr&communicator,
const ::Ice::StringSeq&args)
{
initializeQtForIceBoxService(args);
try
{
Ice::PropertiesPtr properties = communicator->getProperties();
std::string identity = properties->getProperty("Bt.Service.Identity");
std::string adapterName = properties->getProperty("Bt.Service.Adapter.Identity");
_CrtDbgBreak() ;
m_adapter = communicator->createObjectAdapter(adapterName);


Ice::ObjectPtr pObject = new TIceBoxServiceInterface(communicator);
m_adapter->add(pObject, communicator->stringToIdentity(identity));
m_adapter->activate();
}
catch(const ::Ice::LocalException& ex)
{
DEBUGTRACE(dbASSERT|dbERROR,QString("IceBox Service initialization failed: ") + ex.what()) ;
}
}


The first issue:

communicator->createObjectAdapter(adapterName);

fails, with a hard coded name or the property I alias to the name.

As I understand it, the adapter name has to match the value in the xml file for the service template:

<adapter name="$(name)" endpoints="default" id="${server}.${service}.AlsService-$(name)" replica-group="ArchiveGroup" server-lifetime="false">

Is this correct? I have attached an image of the error I am getting.

I also believe that the identity string for the object as used here:

m_adapter->add(pObject, communicator->stringToIdentity(identity));


needs to match the value in the

<replica-group id="OssGroup">
<description>Group of OSS services</description>
<load-balancing type="round-robin" n-replicas="0"/>
<object identity="OssServiceControl" type="::Bt::IServiceControl"/>
</replica-group>

This is so that the client can use the locator and find the object adapter
Are these understandings correct?

thanks
Rich

Comments

  • bernard
    bernard Jupiter, FL
    Hi Rich,

    The adapter name (not to be confused with the adapter id) uniquely identifies an object adapter within a communicator, and allows Ice to look-up the adapter's configuration.

    Ice raises an exception when a named adapter has no associated configuration, as this always corresponds to a mismatch between the name in the code and the name in the configuration (possibly generated from an IceGrid XML descriptor). (If you ever need to create an adapter without any configuration at all, you should give it an empty name).
    std::string adapterName = properties->getProperty("Bt.Service.Adapter.Identity"); 
    

    If you want to have a property for the adapter name (instead of hard-coding it), I would recommend a property name like Bt.Service.Adapter.Name; xxx.Identity would typically represent the stringified identity of an Ice object, like "foo/bar". And you don't want to confuse adapter-name and adapter-id!
    As I understand it, the adapter name has to match the value in the xml file for the service template:

    <adapter name="$(name)" endpoints="default" id="${server}.${service}.AlsService-$(name)" replica-group="ArchiveGroup" server-lifetime="false">

    Is this correct?

    Yes. adapterName should match the actual value of this $(name) parameter.
    I also believe that the identity string for the object as used here:

    m_adapter->add(pObject, communicator->stringToIdentity(identity));


    needs to match the value in the

    <replica-group id="OssGroup">
    <description>Group of OSS services</description>
    <load-balancing type="round-robin" n-replicas="0"/>
    <object identity="OssServiceControl" type="::Bt::IServiceControl"/>
    </replica-group>

    Yes, assuming m_adapter is associated with this replica group, you need to add a servant with identity "OssServiceControl" in this adapter.
    This is so that the client can use the locator and find the object adapter

    When a client resolves the indirect proxy "OssServiceControl", it contacts the locator (IceGrid registry), who returns a direct proxy with the actual addresses (and port numbers) of the active adapters hosting the corresponding servants.

    I hope this is clearer now.

    Best regards,
    Bernard
  • Bernard,

    thanks for the clarification, and the correction for identity vis name.

    Can you explain why the error that is shown in the image occurs then?
    the text of the message is:
    object adapter 'Oss ' requires configuration


    That exception is thrown in
    m_adapter = communicator->createObjectAdapter(adapterName);
    

    It is my understanding that the adapter name and the name in the xml config file are both Oss, so this should have worked correctly....

    thanks
    Rich
  • benoit
    benoit Rennes, France
    Hi,

    This message indicates that the adapter configuration is still missing so the name for the adapter in the XML is most likely still not matching the name that you use in the code to create the object adapter.

    According to the message, the adapter name is 'Oss ' in the code (is the extra space expected?).

    You can check the configuration of the server by looking at the configuration file that IceGrid generates from the XML. This file is located in the <node data directory>/servers/<server id>/config directory. For an IceBox service, the configuration file is named config_<service>.

    If you can't find what the problem is, can you post the full XML descriptor?

    Also, why do you use a variable for the adapter name in the descriptor? It would be easier to just use a fixed name (e.g.: "<adapter name="Oss" ...>") and use this same name in the code to create the object adapter ("com->createObjectAdapter("Oss");")

    Cheers,
    Benoit.
  • Hi Benoit,

    the extra space is an artifact of me typing the message in. you cant copy the text out of the error dialog. If you look at the png image the name is 'Oss'; so it should have worked...

    I reran the scenario loading the new xml file. I am getting the same. Could the problem here be that the config_Oss file has $(name) in it? I would have expected that to be expanded at that point.

    I have zipped the config_Oss file and the xml file (and some other config files) in an attachment.

    Is there a way to have icegrid dump the adapters its got registered so we can see what names were created?

    Please correct me if I am wrong, but working off the examples and the documentation it seems to indicate that the adapter name needs to be parameterized since we can be launching the same icebox service with multiple instances due the replica group, which we are planning on using.

    thanks
    Rich
  • Benoit,

    I found the issue with the createObjectAdapter call, the xml had an incorrect macro that wasnt expanding. After fixing that, I am getting past the step.

    On to stringToIdentity

    thanks
    Rich
  • Bernard,

    I am still having issues within my OssServiceControl object, trying to connect to the AlsServiceControl object in another icebox within the icegrid.
    This is all configured by the previously attached icegrid xml file.

    using:

    the client which is trying to connect with
    Ice::ObjectPrx proxy = communicator->stringToProxy("AlsServiceControl");	
    m_LoggerService =  BtAls::IAlsServiceControlPrx::checkedCast(proxy) ;
    

    The checkedCast always fails; Is this the correct way to connect to a replicated adapter?

    Is there anyway to dump out the icegrids locator information, so I can see what is actually defined? the java ui tool isnt very helpful in that way.

    thanks
    Rich
  • bernard
    bernard Jupiter, FL
    Hi Rich,

    checkedCast returns 0 when the target object does not implement the requested interface. Does the servant associated with identity "OssServiceControl" implement the Slice interface BtAls::IAlsServiceControl?

    The checkedCast always fails; Is this the correct way to connect to a replicated adapter?

    This is the correct way to connect to an _object_ (here a 'replicated' object). The object adapters are local to each servers, and are not directly accessible by the clients.

    Best regards,
    Bernard
  • Bernard,

    thanks for the response. I see now that in fact it was implementing the super interface and not the sub interface. It is working now.

    my bad...

    thanks
    Rich