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]
