It would certainly be possible to add a removeTopic() to NotificationProducer which would remove the topic from the internal data structures and kill any subscriptions on that topic; we would need this to support un-fixed topic sets, so please create a JIRA item. At the same time, I think we should try and agree on the nature of topics and how they relate to resources and clients to make sure Muse and your project are standards-compliant.
The behavior you describe sounds more like a subscription than a topic - a subscription is an agreement that results in messages being sent from a producer to a consumer, and the agreement can be terminated by either party. Many consumers can receive the same information from one producer, and topics help the producer determine which consumers want to receive which messages. The subscriptions help the producer by a) telling it that a consumer is even listening, and b) the general info about what kind of messages they're listening to. In this sense, a subscription is similar to an HTTP session (it adds state to an otherwise stateless system, can be cancelled by either party, acts as an identifier for otherwise anonymous clients, etc.). The topics are predefined by the capabilities in your resource type - if they're not, a client/consumer will never know the full range of topics available to it, and thus cannot subscribe to them. Based on the WSN spec, I can't see how you'd relate topics/sessions *unless* you knew all of your consumers ahead of time. Can you explain where you see deviations from this explanation? Thanks, Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 01/02/2007 02:58:39 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
