Thanks Dan,
Happy New Year to your team!

The NotificationProducer interface has an addTopic(), but no
corresponding removeTopic().  So basically, it can accumulate an
unlimited number of topics and never be able to cleanup expired ones.
For our implementation, we can generate dynamic topics associated with a
session.  The topics should expire when the session is over.  The number
of topics can be large, depending on the number of sessions.

1) Is there an existing implementation that can remove previous topics?
I can build my own custom NotificationProducer class, but hopefully this
is only a temporary solution.
2) I took a quick look at the SimpleNotificationProducer class.  It
defines a fixed topic set, so it doesn't have the ability to remove
previous topics.  Internally, it maintains two different data structures
for storing the topics (one hierarchical, and one non-hierarchical, so I
can't simply call getTopicSet.removeTopicNamespace() as I originally
thought I could.

 

-----Original Message-----
From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 02, 2007 8:08 AM
To: [email protected]
Subject: Re: destroy notification topics

1. The list of topics exists independent of how many subscribers there
are. I would make an analogy to radio stations: whether a station has
zero or a thousand listeners, it still exists. If there are zero
listeners, the station still exists and will be available should someone
tune the dial to it. Similarly, topics are part of a resource's
interface and do not increase or decrease based on subscribers.

2. No - the WSN spec only allows you to pause subscriptions, not topics.

In order to pause all subscriptions that sent out messages on a given
topic, you'd have to iterate through all of the subcriptions, find the
ones that were topic-oriented, and pause them.

If you wanted to do this as a server-side operation, the easiest way
might be to extend SimpleNotificationProducer and plug the new class in
as your WSN implementation (in muse.xml). Something like this:


class PausableNotificationProducer extends SimpleNotificationProducer {
        public void pause(QName topicName)
        {
                Iterator i = getSubscriptions().iterator();

                //
                // for each subscription we currently have...
                //
                while (i.hasNext())
                {
                        //
                        // use the WSN SubscriptionManager capability to

                        // find the subscription's filter type
                        //
                        WsResource subResource = (Subscription)i.next();
                        SubscriptionManager subMgr =
subResource.getCapability(WsnConstants.SUBSCRIPTION_MGR_URI);
                        Filter filter = sub.getFilter();

                        //
                        // if it uses topics, compare the topic names
                        //
                        if (filter instanceof TopicFilter)
                        {
                                TopicFilter topicFilter =
(TopicFilter)filter;
                                QName subTopic = topicFilter.getTopic();

                                //
                                // we have a match - shut it off
                                //
                                if (subTopic.equals(topicName))
                                        subMgr.pauseSubscription();
                        }
                }
        }
}



"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/19/2006
03:42:44 PM:

> A subscribe request must specify zero or one topic.  So suppose 
> several clients are subscribed to the same topic.
> 
> 1) If all clients unsubscribe, does Muse still hold on to the topic?  
> If so, how do we prevent Muse from building up a list of unused 
> topics, if it does keep such a list?
> 
> 2) Is there a way to destroy/pause a topic, and effectively stop its 
> corresponding notifications from being sent out, without killing the 
> subscriptions?  Then be able to resume the topic and notifications at 
> a later time?
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to