[
https://issues.apache.org/jira/browse/CAMEL-25280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122172#comment-18122172
]
Claus Ibsen commented on CAMEL-25280:
-------------------------------------
Merged via https://github.com/apache/camel/pull/27309
_Claude Code on behalf of davsclaus_
> camel-snmp - concurrent exchanges on one endpoint share the producer's
> request PDU, so a GET_NEXT walk can silently return another walk's subtree or
> an incomplete result
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25280
> URL: https://issues.apache.org/jira/browse/CAMEL-25280
> Project: Camel
> Issue Type: Bug
> Components: camel-snmp
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> {{SnmpProducer}} creates one request {{PDU}} in {{doStart}} and keeps it in a
> field. The producer of an endpoint is shared by all the exchanges that use it
> at the same time (a REST route, {{parallelProcessing}}, several consumers
> calling the same endpoint), and the {{GET_NEXT}} walk changes that PDU for
> every request ({{pdu.clear()}}, then the next OID). SNMP4J also keeps the PDU
> object of a request and encodes it again when it retries after a timeout.
> So two walks on one endpoint at the same time change each other's requests.
> Reproduced: when a request of the first walk is retried while a second walk
> runs, the retry sends the OID that the second walk requested last; the answer
> belongs to the other subtree, so the first walk ends its subtree early and
> returns a shorter list, without any error. Without a retry the same
> interleaving can happen between {{pdu.clear()}} / {{pdu.add()}} and
> {{snmp.send()}} of the two threads.
> h3. Reproduction
> {{ConcurrentWalkTest}}: an SNMP4J test agent with two subtrees
> ({{1.3.6.1.4.1.9999.1}}: a1, a2; {{1.3.6.1.4.1.9999.2}}: b1, b2) that does
> not answer the very first request; an endpoint
> {{type=GET_NEXT&oids=1.3.6.1.4.1.9999.1,1.3.6.1.4.1.9999.2&timeout=2000&retries=1}}.
> The first walk is started, and once its first request was dropped a second
> walk runs on the same endpoint. The second walk gets {{[a1, a2, b1, b2]}}; on
> main the first one gets {{[b1, b2]}} ({{expected: <[a1, a2, b1, b2]> but was:
> <[b1, b2]>}}).
> h3. Proposed fix
> Create the request PDU for each exchange (the code that built it in
> {{doStart}} moves to a method called by {{process}}); {{doStart}} keeps the
> USM and the target. With the fix the new test and the camel-snmp suite (22
> tests, on main after CAMEL-25245) pass.
> Affected: 4.14.x, 4.18.x and main (the walk changes the shared PDU since
> CAMEL-13936, 3.0).
> Duplicate check (2026-10-02): JIRA component camel-snmp (26 issues):
> CAMEL-25245 (fixed, mentions this as not in scope), CAMEL-13936, CAMEL-3110,
> CAMEL-12946 (consumer dispatcher), nothing about concurrency of the producer.
> GitHub pull requests "snmp": only #27242 (CAMEL-25245, merged).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
