Good points. However my intention was to avoid method calls like these - atleast in one usage of the Muse programming model, the capabilities are threaded and would like to save as much time as possible in responding to method calls that may not make sense to them. Maybe an intermediate approach can be used - overload the existing registration method and the NotificationConsumer can keep a lookup hashtable - listeners who do not provide a topic during registration are kept in a "catch-all" bucket. When a notification message arrives, only pick up the listeners against the topic in the hashtable and call process on them. Also call accepts() regarldless on everything in the catch-all bucket.
The advantage really is that only one QName.equals() is done instead of it being done in each capability as will be the case now assuming topic and xpath is used for filtering (which is also a valid usecase atleast in this one implementation). I guess this is coming down to being very anal but we are trying to reduce as many method calls on capabilities as possible in this implementation. Balan Subramanian Autonomic Computing, IBM, RTP, NC 919.543.0197 | [EMAIL PROTECTED] Daniel Jemiolo/Durham/[EMAIL PROTECTED] 01/05/2007 09:02 PM Please respond to [email protected] To [email protected] cc Subject RE: Potential performance issue with NotificationListeners Your last paragraph was the point I was most concerned with - topics are only one type of subscription filter, and there is a large camp of people (not me ;) who think that xpath-based filtering is a great idea. Also, given that the topic filtering is a simple call to QName.equals() (which is two calls to String.equals()), I'm not sure how much you'd gain without actual test data to look at. In the case where the topics don't match, the QName.equals() call will probably short circuit early because the namespaces will be different after a few chars; in the case where they do match, will the time used on accepts() be meaningful when compared to that in process()? I don't know. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 01/05/2007 08:52:54 PM: > I ran into this issue before, too. Basically, when a consumer resource > receives a notification, it iterates through its list of listeners. It > first calls accepts(), and then any listener that responds with "true" > will be given the message via a call to process(). > > I think the suggestion is that instead of the resource having to iterate > thru all listeners, a different design could be used. When a listener > registers itself to the consumer resource, it should specify a topic, > too. This way, the resource can map which listeners want which topics, > and then only call those listeners when a message is received. It's > more of an efficiency thing, which especially becomes more apparent when > a large number of notification messages can be received. The current > design can be O(n^2) (#messages X #listeners), and the suggested design > can possibly be half of that. > > But then, I think there may be more cases where the current design is > better. There can be many possible ways to filter a message by (i.e. by > topic, message type, pattern, producer EPR, etc), so mapping listeners > by topic may only increase efficiency by a small amount. > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Friday, January 05, 2007 5:35 PM > To: [email protected] > Subject: Re: Potential performance issue with NotificationListeners > > I'm not sure I understand - addMessageListener takes an object that > implements NotificationMessageListener, and since you right those > classes, they can contain any supplemental info you'd like. If you > wanted a listener that filtered on topics, you could use code that is > similar to that found in the wsn-producer sample. The code below > generalizes the sample code a bit, so that you can use it to filter on > any topic: > > > public class MyTopicListener implements NotificationMessageListener { > private QName _topicName = null; > > public MyTopicListener(QName topicName) > { > _topicName = topicName; > } > > public boolean accepts(NotificationMessage msg) > { > QName msgTopicName = msg.getTopic(); > return msgTopicName != null && > msgTopicName.equals(_topicName); > } > > public void process(NotificationMessage msg) > { > ... > } > } > > > Then, you can add this listener as follows: > > > NotificationConsumer wsn = > getResource().getCapability(WsnConstants.CONSUMER_URI); > NotificationMessageListener listener = new MyTopicListener([your topic > name here]); wsn.addMessageListener(listener); > > > > Of course, even with this, you're right, the consumer capability is > still calling accepts() for each listener to see if they want to respond > to the message. I don't really see how this would be avoided; if you > want all of your listeners to respond to the exact same topic, it would > probably be easier to sub-class SimpleNotificationConsumer and add the > following > override: > > > public class MyTopicNotificationConsumer extends > SimpleNotificationConsumer { > public void notify(NotificationMessage msg) > { > QName topic = msg.getTopic(); > > if (topic == null || !topic.equals([your topic name > here]) > // throw fault > > super.notify(msg); > } > } > > > If you have listeners that are acting on different messages > types/topics/patterns, though, it seems to me that all listeners have to > test it. > > Dan > > > > Balan Subramanian/Raleigh/[EMAIL PROTECTED] wrote on 01/05/2007 05:42:37 PM: > > > When registering NotificationListeners with the NotificationConsumer, > the > > registering capability only provides a reference to itself but no > > indication of which Topic it wants to subscribe to. It does a separate > > > subscribe operation on the topic with the EPR of the resource. > > > > However when a notification message is received, the notification > consumer > > capability has to call accepts() method on each of the registered > > listeners. This seems like a performance issue if you have many > > capabilities and many notifications coming in. > > > > It would be better if the addMessageListener() also took a topic name. > > Or > > rather, a new method can be provided like setupSubscription() on the > > notification consumer that will also subscribe to the actual topic > instead > > of the capability having to do this. > > > > if my understanding of the way this works is wrong, please excuse my > > ignorance and provide an explanation of the mechanism. also are there > > other cases in which subscriptions will have to be made by the > > capabilities only? > > > > Balan Subramanian > > Autonomic Computing, IBM, RTP, NC > > 919.543.0197 | [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
