Snmp4j and virtual threads

SNMP4J
1

Hi there,

we’d like to use snmp4j to scale to 1000s (potentially 10000s) parallel SNMP sessions. Each sessions fetches a rather large number of (mainly repeater) OIDs - e.g. MIB-2 ifTable.
We’re already on JDK21, so virtual threads are available. We use them in our application to schedule SNMP polls and process results.
When it comes to snmp4j, I’m aware of two areas where threading is involved for our use case:

  • TransportMapping (we use DefaultUdpTransportMapping)
  • Timers (for retransmission / timeout handling in sessions)

Current assumption is, that also using virtual threads for transport mappings and timers further enhances scaling capabilities.
A quick test with Thread factories using virtual threads instead of platform threads (using SNMP4JSettings.setThreadFactory and SNMP4JSettings.setTimerFactory) led to some locking issues. On first sight it seems like all platform threads acting as carrier threads (Fork-Join pool) are exhausted due to blocking I/O operations in synchronized blocks.
Does this seem like a reasonable explanation for SNMPSession.get() / SNMPSession.walk() not returning in finite time?
Are there any plans to make snmp4j “virtual thread ready” by using ReentrantLock or the like instead of synchronized locking?

thanks and best regards,
Stefan

2

Hi Stefan,
Why would you like to use 1000 or more ports (-> Snmp sessions) on a system?
Why not using a single Snmp session for that?

The next major version will use new locking mechanisms where possible.

Nevertheless I do not think that virtual threads will improve throughput by themselves.
Best regards,
Frank

3

Hi Frank,

thanks for your prompt response.

Very good and valid question :wink: To be honest I took it for granted that a snmp4j session maps to a single target, since a few wrapper classes in our app made that assumption. Should have questioned that to start with.

That’s good news, thanks. And I totally agree that virtual threads aren’t a silver bullet. They’re just good in waiting for blocking things to happen.
Since I’m a network guy I like the QoS analogy: QoS doesn’t create bandwidth, it’s just managed unfairness :slight_smile:
Will happily go ahead and refactor some wrapper classes …

Thanks for your help!
cheers,
Stefan