Archived

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

IceStorm: subscriber: object adapter requires configuration

I'm very new to Ice. This is probably a very simple question to answer.

I'm trying out IceStorm pub/sub on my own. I think Pub and icebox are running fine. However, when I start running subscriber I get the following:

Ice::InitializationException: initialization exception: object adapter 'xxx.Subscriber' requires configuration.

I'm merely following the Ice documentation (page 1711) almost exactly the same...what went wrong?

Here's my code snippet, the last line is throwing an exception:
int main()
{
  try
  {
    // Establish a communicator
    Ice::CommunicatorPtr communicator = Ice::initialize();
    Ice::ObjectPrx       obj          = communicator->stringToProxy("DIceStorm/TopicManager:default -p 9999");

    // Obtain Topic Manager Proxy
    IceStorm::TopicManagerPrx manager = IceStorm::TopicManagerPrx::checkedCast(obj);
    if(!manager)
    {
      throw std::exception("!manager");
    }
    // Subscribe to SasData topic
    IceStorm::TopicPrx topic = manager->retrieve("SasData");

    // Create an object adapter to host the SasData servant
    Ice::ObjectAdapterPtr adapter = communicator->createObjectAdapter("SasData.Subscriber");

I also noticed in Ice C++ demo that subscribers seem to load the config.sub, what's the easy way to load such file without inheriting from Ice::Application? Is that even necessary?

Comments

  • mes
    mes California
    Hi,

    Welcome to the forum!

    You're getting the exception because you're creating an object adapter via the createObjectAdapter operation, and this operation expects you to define at a minimum the configuration property that supplies the object adapter's endpoints. In your example, you would need to define this property:

    SasData.Subscriber.Endpoints=tcp

    The value you supply for this property may need to change based on your requirements. In the example above, your subscriber's object adapter will be listening for callbacks from IceStorm on a system-assigned port and on all available network interfaces.

    You can achieve the same effect using the createObjectAdapterWithEndpoints operation:
    Ice::ObjectAdapterPtr adapter =
        communicator->createObjectAdapterWithEndpoints("SasData.Subscriber", "tcp");
    

    It's no longer necessary to define the configuration property in this case.
    I also noticed in Ice C++ demo that subscribers seem to load the config.sub, what's the easy way to load such file without inheriting from Ice::Application? Is that even necessary?
    No, it is not necessary to use Ice::Application. If you want to load a configuration file, you can do it like this:
    Ice::InitializationData initData;
    initData.properties = Ice::createProperties();
    initData.properties->load("config.sub");
    Ice::CommunicatorPtr communicator = Ice::initialize(initData);
    
    Alternatively, you can pass the --Ice.Config option on the command-line, but this requires you to pass your program's argument vector to initialize or to createProperties.

    Also, don't forget to activate your object adapter.

    Regards,
    Mark
  • Thank you!

    Whao, that was fast. :)

    I will try it out tomorrow, and post here as a conclusion (I'm sure it will work).

    Thanks again!
  • Yippee!! It works!

    Mes,

    Thank you! It works! Just a one liner change!

    I also tried running 2 subscribers in parallel, and it worked like a charm. I haven't tested the performance but this is looking real good.

    It's awesome to be able to easily implement Pub/Sub pattern with just a few lines of codes.

    Some comments though:

    1) It would be real nice if IceBox is not needed to get Pub/Sub working. Or is my understanding incorrect?

    2) Is the IceBox there just to allow Sub to discover the Pub's Topic? Or does Icebox also handles data transmission? Because if IceBox handles data transmission too, would Ice's Pub/Sub really scale in terms of performance? I also tried closing IceBox process, and found that the Pub/Sub stopped.

    3) What would happen if a subscriber takes a very long time to process a message. (i.e. the subscriber can process a message at a slower pace than the publisher producing the data). How does Ice "queue up" the messages? At what point will the queue be full? Or is that the wrong way of understanding Ice's Pub/Sub? Can the programmer specify the QoS?

    4) I'm also comparing Ice's Pub/Sub with DDS. I'm about to try out OpenSplice DDS actually. Do you have any thoughts RE: implementation difference between DDS and IceStorm?

    All in all, I'm pretty impressed.
  • mes
    mes California
    ShaChris23 wrote: »
    1) It would be real nice if IceBox is not needed to get Pub/Sub working. Or is my understanding incorrect?
    IceStorm is the "middleman" service that handles all of the publish-subscribe activities, including topic management and event distribution. Publishers connect to IceStorm and send their events to IceStorm for delivery to the subscribers. The IceStorm service runs as a loadable module inside the generic IceBox server.

    One advantage of using an intermediary such as IceStorm is that it decouples the publishers from the subscribers: each side needs to know about IceStorm, but they don't necessarily need to know about each other.
    2) Is the IceBox there just to allow Sub to discover the Pub's Topic? Or does Icebox also handles data transmission? Because if IceBox handles data transmission too, would Ice's Pub/Sub really scale in terms of performance? I also tried closing IceBox process, and found that the Pub/Sub stopped.
    Yes, the IceStorm service is required. If scalability becomes an issue you can run multiple IceStorm services and establish links between them.
    3) What would happen if a subscriber takes a very long time to process a message. (i.e. the subscriber can process a message at a slower pace than the publisher producing the data). How does Ice "queue up" the messages? At what point will the queue be full? Or is that the wrong way of understanding Ice's Pub/Sub? Can the programmer specify the QoS?
    IceStorm will queue messages for a slow subscriber, but the queue is not persistent. In other words, all queued messages are lost when the IceStorm service terminates. IceStorm does provide some QoS options as well.

    I suggest reading over the IceStorm chapter in the manual, as well as the newsletter articles on the subject.

    Also note that IceStorm is one approach to implementing publish-subscribe with Ice, but is certainly not the only way to go about it. IceStorm is implemented as a regular Ice application using the public Ice API, just like any application you might write. The Ice core has no special publish-subscribe API nor any knowledge of IceStorm, so you could implement your own system if IceStorm doesn't meet your requirements.

    Regards,
    Mark