JBoss SNMP for sending Get requests

[dpocock]

JBoss includes the joeSNMP stack for sending traps and responding to some Get requests. However, the documentation does not discuss the possibility of sending Get requests from an application running inside JBoss.

Is it safe to send get requests from within an EJB? If yes, how will the callbacks be received, or will the request block?

Will joeSNMP start threads in a JBoss compliant manner when sending get requests?

joeSNMP defines an SnmpHandler interface, with a callback:

public void snmpReceivedPdu(SnmpSession session, int cmd, SnmpPduPacket pdu);

to be implemented within the application. Are the callbacks made from within container managed threads?

[dimitris]

joesnmp does not have any special integration with the jboss thread pools. When in "agent" mode, if configured to use a thread pool by setting the agent NumberOfThreads attribute, it creates it's own thread pool to serve incoming get/set requests.

AFAIK, when joesnmp is used to do outgoing get/set requests, it creates one or two threads for processing them, again, nothing to do with jboss threads.

Maybe it is better for you to abstract all joesnmp functionality within an mbean called by your EJBs. This doesn't improve integration of threads with jboss thread pools, but it at least will give you more control over managing snmp "sessions".

[dpocock]

Thanks for clearing that up. I was thinking that a JCA resource adapter might be a better solution - would you agree?

However, despite searching online, I haven't found any examples of how JCA should be used to access SNMP services. I've put together some notes on how I would implement this, but maybe someone else has some better suggestions?

Each `Connection' would correspond to a locally initiated SnmpSession to a remote agent.

The SNMP tree could be modelled as a database (using the ResultSet model of JCA), or we could just use the joeSNMP API, but with everything passed through the Connection object.

The resource adapter is permitted to start threads (although the spec recommends using WorkManager) - joeSNMP could probably be further hacked to delegate thread creation to WorkManager.

The final issue is the callbacks - the Get requests could be sent synchronously, so the application would have to block, or the responses could be sent by JMS. Blocking isn't such a bad idea - the calling application should use a Work object for lengthy tasks, such as walking the whole tree.

[dimitris]

A JCA adapter would be the right approach, but it's harder to write one. Given that you won't be doing any transaction and security context propagation, the only benefit would be if you manage to use the server threads, but again, only if you hack joesnmp :)

The way you describe a possible JCA looks right.

[dimitris]

In any case, if your changes to joesnmp are generic/useful enough, and preferably backwards compatible, we could incoprorate them to a future version of joesnmp at sourceforge, as I have commit rights there.

[dpocock]

Some more issues that come to mind:

- how would you see the existing agent interacting with the resource adapter?

- how would this fit into the classpath - where should the joeSNMP JARs go so that applications can use them?

[dimitris]

I guess, they could operate independently.

As it is now, the joesnmp jars are shared in the static lib directory, so no need to include them with a RAR.

[dpocock]

I've been looking at how to generalise joeSNMP to use WorkManager.

I've discovered that JBoss's WorkManager doesn't register in JNDI. Is that normal? Is WorkManager only available within a resource adapter (RA), or should it be in JNDI for use by any type of application?

[dimitris]

I'd say it's only available for RAs, but better ask this in the JCA forum :)