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: [email protected] [mailto:[email protected]] On Behalf
Of Frank Fock
Sent: Wednesday, January 20, 2010 5:34 PM
To: [email protected]
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, [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
_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j
