Please look carefully at the source. The CommandProcessor uses itself a NotificatonOriginator to actually send out notifications. The AgentConfigManager sets that NotificatonOriginator at the CommandProcessor with its own. So everything is fine.
On 20.01.2010 23:27, [email protected] wrote: > By default, AgentConfigManager creates a new NotificationOriginatorImpl. That > class sends notifications serially because they are all sent on the calling > thread. > > A CommandProcessor implements the NotificationOriginator interface and knows > to dispatch notification tasks to its workerPool. There are no other > implementations of the NotificationOriginator interface. So if we want to > send Notifications in parallel, we have to call > AgentConfigManager.setNotificationOriginator with a CommandProcessor. > > There is already a CommandProcessor with a worker pool in AgentConfigManager > but it's only used to execute requests. Why is the AgentConfigManager not > using the CommandProcessor as its NotificationOriginator? If it is not > possible, then why is the CommandProcessor also a NotificationOriginator? > _______________________________________________ > SNMP4J mailing list > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
