[SNMP4J] multithreaded NotificationOriginator

Clement_Pellerin at ibi.com Clement_Pellerin at ibi.com
Thu Jan 21 01:38:08 CET 2010


I had not noticed, but I agree with you that the notification originator used by the snmpv2MIB is multi-threaded.

    if (notificationOriginator == null) {
      notificationOriginator = createNotificationOriginator();
    }
    agent.setNotificationOriginator(notificationOriginator);
    // Use CommandProcessor instead notificationOriginator to send informs non
    // blocking.
    snmpv2MIB.setNotificationOriginator(agent);

My problem occurs because I call AgentConfigManager.getNotificationOriginator() and that returns the single-threaded notification originator. The CommandProcessor in the AgentConfigManager is a protected member and there are no accessors so there is no clean way to get the multi-threaded notification originator except by sub-classing AgentConfigManager. This makes me say there is a small gap in the API of AgentConfigManager.

The work-around is simple enough to implement in my application, but the assumption that the originator is multi-threaded is too easy to make. At the very least, this requires a comment in AgentConfigManager.getNotificationOriginator() to warn people that they might prefer the CommandProcessor instead.

-----Original Message-----
From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org] On Behalf Of Frank Fock
Sent: Wednesday, January 20, 2010 5:34 PM
To: snmp4j at agentpp.org
Subject: Re: [SNMP4J] multithreaded NotificationOriginator

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, Clement_Pellerin at ibi.com 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
> SNMP4J at agentpp.org
> 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
SNMP4J at agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j



More information about the SNMP4J mailing list