Archived

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

IceStorm: how to init the subscriber?

Ryuga
Ryuga
in Help Center
Hello,
it's the first post, so I'd like to greet everybody and apologize for my poor vocabolary... ;)

I've to face the problem about the initialization of a newly added subscriber. In my project I have:
1 a publisher that has some data (let's say a list of strings) and, at a certain point starts to publish the changes on them.
2 some subscribers that start to listen to the publisher's messages about changes on the list of strings

The porblem is that when the subscriber subscribes the topic (on which the publisher is publishing), it needs to receive the whole status of the list.

In the manual I've found the example in the section "41.6 Publishing to a Specific Subscriber" about the ListObserver.
As I understand it (and I may be wrong) it says that in the subscriber thread I can store the proxy returned by the subscribeAndGetPublisher call and then call an 'init' method on it to publish the event to the specific subscriber... but who can I get the state of the list since this code and this proxy is in the publisher thread?

This same situation is shown at page 1587 of the Ice-3.3.0.pdf:

Ice::ObjectPrx pub = topic->subscribeAndGetPublisher(qos, proxy);
MonitorPrx monitor = MonitorPrx::uncheckedCast(pub);
Measurement m = ...;
monitor->report(m); // Sent to only to this subscriber

again this is the subscriber thread: so how can I get the Mesurement m to to sent it to the newly subscriber monitor via it's 'report' method?

I think there's something I''m missing, please help is greatly apreciated.
Tnx

Comments

  • matthew
    matthew NL, Canada
    For this type of use-case typically you'd manage the subscription and other necessary state outside of IceStorm, by some service.

    For an example, take a look at demo/IceStorm/counter in the C++ distribution.
    void
CounterI::subscribe(const CounterObserverPrx& observer, const Ice::Current&)
{
    Lock sync(*this);

    //
    // Subscribe to the IceStorm topic. This returns a per-subscriber
    // object which is then used to send the initialize event to just
    // the given subscriber.
    //
    CounterObserverPrx o = CounterObserverPrx::uncheckedCast(
        _topic->subscribeAndGetPublisher(IceStorm::QoS(), observer));
    o->init(_value);
}

    This is the magic that ensures that the subscriber is subscribed and initialized race condition free by using the subscriber specific publishing object.
  • Ryuga
    Ryuga
    Tnx,
    I'll see the example to figure it tou how it works... if I'll be in trouble again I'll ask more info.
    Bye
  • Ryuga
    Ryuga
    Some more info, please

    Hi,
    I've gave a look to the counter example and I've got come questions/considerations to share if possible...
    What I understood from the example is that 2 interfaces are declared: the first is for the normal observer(CounterObserver) and another is for handling the subscribe/unsubscribe and the other operations appliable to the observer (Counter).
    The mechanish is the one that follows:
    1 The subscriber creates a proxy to be able to send it's observer to the publisher.
    2 The subscriber creates the normal structure for being able to receive the publisher messages (that are the adapter and the servant).
    3 The subscriber calls subscribe on the publisher's proxy passing it's observer.
    4 The publisher responds to the subscribe message by subscribing the passed observer to the topic.

    Is it's correct, then the subscriber cannot be launched before it's publisher (for it's the publisher that does the subscription).
    How can I avoid this? I was thinking of an IceBox (that launches the publisher if a subscribers requires it)... is it a good idea?

    Tnx in advance for the info.
  • matthew
    matthew NL, Canada
    How can I avoid this? I was thinking of an IceBox (that launches the publisher if a subscribers requires it)... is it a good idea?

    From your description, I think you understand the counter demo well. Here I suspect you mean IceGrid, not IceBox (which is a container for services, not an activation daemon).

    If your subscribers require some initial state before they start, then some service must keep track of that state. It also follows that you cannot start a new subscriber without that service running. Using IceGrid is one way to ensure that prerequisite is met.
  • Ryuga
    Ryuga
    Ops, sorry IceGrid is what I ment.
    Tnx very much for your advices... I'm implementing that logic in my project now.
    Bye

Categories