[
https://issues.apache.org/jira/browse/CAMEL-26751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26751:
--------------------------------
Fix Version/s: 4.24.0
> camel-sanitizer - R1 still pending: warn about a step whose callback has not
> come
> ---------------------------------------------------------------------------------
>
> Key: CAMEL-26751
> URL: https://issues.apache.org/jira/browse/CAMEL-26751
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
> Attachments: camel-26751-sanitizer-pending-tla.tar.gz
>
>
> Step 6 of the order of work in the exchange sanitizer design
> ({{design/exchange-sanitizer.adoc}}, CAMEL-26630): rule R1 "still pending",
> on top of the {{camel-sanitizer}} module of CAMEL-26714.
> As in the design (R1, "Still pending"):
> * A call of a step whose callback has not come after
> {{camel.sanitizer.pendingTimeout}} (default 60s) is a *warning*, not a
> violation, as a slow endpoint looks the same. It is logged at WARN and never
> fails a test.
> * Only the innermost pending call of an exchange is reported, timed from the
> last call or callback of that exchange, so a long split or a
> {{to("direct:...")}} that waits for its children is not. The copies that a
> split, multicast, recipient list, enrich, kamelet, circuit breaker or
> {{to("kamelet:...")}} step waits for count as the exchange they belong to
> (they carry its id as their correlation id; other copies, such as the one a
> seda producer queues, are exchanges of their own).
> * The warning names the exchange, route, step, the processor (the class of a
> user's processor) and the endpoint, says whether {{process}} returned, threw
> or has not returned yet (then with the stack of the thread still in it), and
> lists the enclosing calls that wait for it. This is what the {{inflight}}
> console cannot tell: which step's callback the exchange waits for, and
> whether that step threw.
> * When the context stops, the calls still pending are listed.
> * The pending calls are kept in a bounded table that holds ids and names, not
> the exchanges (10,000 calls; past that the oldest is dropped, counted, and
> one WARN says the checks are incomplete). An exchange that is done (its unit
> of work) is dropped, so a call that threw and that Camel handled is not
> reported.
> * The new option is part of the {{SanitizerConfigurationProperties}} group of
> camel-main; {{0}} turns the warning off.
> The design's validation for this step: the hangs of CAMEL-26575 (an
> {{AggregationStrategy}} whose {{onCompletion}} throws in a multicast) and
> CAMEL-26601 (a recipient producer that throws inside {{doTry}}), which R1
> could not show, reported at the multicast and recipient list step with the
> fixes reverted; and the camel-core suite with the CI switch quiet on main.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
