Archived

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

IceStorm service descriptor

Hello Ice experts,

I have a hard time figuring out how to write a service descriptor needed to deploy the IceStorm service on a node. I tried the following

<service kind="standard" entry="IceStormService:create">

<adapters>
<adapter name="IceStorm" endpoints="default">
<object identity="${name}" type="::IceStorm::TopicManager"/>
</adapter>
</adapters>

<properties>
<property name="Identity" value="${name}"/>
</properties>

</service>

but when I use icepackadmin to add my application I get the following warnings:

warning: unknown property: IceStorm.AdapterId
warning: unknown property: IceStorm.Endpoints

and when I try to start the client application, it hangs.

Any help would be appreciated.

Istvan

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Here's a descriptor that should work better (icestorm.xml):
    <service kind="freeze" entry="IceStormService:create">
    
      <adapters>
        <adapter name="${name}.TopicManager" endpoints="tcp">
          <object identity="${name}/TopicManager" type="::IceStorm::TopicManager"/>
        </adapter>
      </adapters>
    
    </service>
    

    The IceBox server descriptor would look like:
    <server kind="cpp-icebox" endpoints="tcp -h 127.0.0.1">
      <service name="IceStorm" descriptor="icestorm.xml"/>
    </server>
    

    Let me know if you still have some problems deploying the IceStorm service with these descriptors!

    Benoit.
  • Hello Benoit,

    thanks for your quick reply.
    I modified my descriptors but unfortunatly the problem persists: the client still hangs.
    When I deploy the application, one of the warning disappeared. The one remaining is:

    warning: unknown property: IceStorm.TopicManager.AdapterId

    The IceStorm service descriptor is a cut and paste of the one you posted.
    My IceBox server descriptor looks like
    <server kind="cpp-icebox" endpoints="tcp -h 127.0.0.1">
      <service name="GConnectService" descriptor="gconnect-service.xml"/>
      <service name="IceStorm" descriptor="icestorm-service.xml"/>
    </server>
    

    GConnectService is an IceBox service I developped myself and it makes use of IceStorm.
    When the client application send its first request to GConnectService, the service starts normally but the client freeze.
    On the other hand, if I comment out the piece of code in GConnectService that set up the IceStorm topic and publisher then the client application doesn't hang.

    Here is how this piece of code looks like
      IcePack::QueryPrx query = 
        IcePack::QueryPrx::checkedCast( communicator->stringToProxy( "IcePack/Query" ) ) ;
    
      //
      // Get an object implementing the IceStorm::TopicManager interface.
      //
      topic_manager_ = 
        IceStorm::TopicManagerPrx::checkedCast( query->findObjectByType( "::IceStorm::TopicManager" ) ) ;
    
      if ( !topic_manager_ )
        {
          throw "Invalid topic manager object reference" ;
        }  
    
      try
        {
          op_topic_ = topic_manager_->retrieve( "GConnectOperation" ) ;
        }
      catch ( const IceStorm::NoSuchTopic & )
        {
          op_topic_ = topic_manager_->create( "GConnectOperation" ) ;
        }
    
      Ice::ObjectPrx pub = op_topic_->getPublisher() ;
      if ( !pub->ice_isDatagram() )
        {
          pub = pub->ice_oneway() ;
        }
    
      op_monitor_ =  Notif::OperationMonitorPrx::uncheckedCast( pub ) ;
    


    I looked more closely at it and found out that the following call never return

      topic_manager_ = 
        IceStorm::TopicManagerPrx::checkedCast( query->findObjectByType( "::IceStorm::TopicManager" ) ) ;
    


    Any idea where to look from here ?

    Thanks,
    Istvan
  • benoit
    benoit Rennes, France
    Hi,

    I think the problem is that your service is initialized first and makes use of the IceStorm service which isn't initialized yet (so when you try to invoke on the IceStorm object, Ice hangs waiting for the object to be activated -- which won't happen since the IceBox for the IceStorm service is being activated and is stuck in the checkedCast call).

    There's currently no way to controll the initialization order of services in an IceBox. I would recommend to deploy your IceStorm service in a separate IceBox server instead and register your 2 servers with IcePack.

    Is there a particular reason why you want to deploy the 2 services in the same IceBox?

    Benoit.
  • Benoit,

    thanks for your help, it works now !!
    As you suggested I created two servers.
    Is there a particular reason why you want to deploy the 2 services in the same IceBox?

    No not really. It was just simpler.
    But I guess that now that I have two different servers, the co-location optimizations don't work anymore ?

    Last question (just out of curiosity). Do you have any plan to add feature to control the order of initialization of services in the future ?

    Thank you very much for your help and for this great piece of software !!

    Istvan