[
https://issues.apache.org/jira/browse/CAMEL-25912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131405#comment-18131405
]
Claus Ibsen commented on CAMEL-25912:
-------------------------------------
Merged to main in https://github.com/apache/camel/pull/28371 (commit
b418ab6acd42), fixed in 4.24.0.
_Claude Code on behalf of davsclaus_
> camel-milo - client producers wait for the manager lock while a subscription
> service call holds it
> --------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25912
> URL: https://issues.apache.org/jira/browse/CAMEL-25912
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Reporter: Serdar Gökay
> Assignee: Serdar Gökay
> Priority: Minor
> Fix For: 4.24.0
>
>
> h3. Problem
> {{SubscriptionManager}} uses one {{lock}} for the subscription work and for
> the producer requests. Registering monitored items, deactivating them when a
> route stops, recreating a subscription and, with CAMEL-25692, creating
> refused items again all hold {{lock}} across a blocking service call. The
> producer methods {{write}}, {{call}}, {{readValues}} and {{browse}}, and
> {{getOpcUaClient()}}, take the same {{lock}}, although under it they only
> read the current connection and start an asynchronous request. A producer
> request therefore waits, with its thread blocked, until the service call that
> holds {{lock}} completes:
> * normally one round trip;
> * during a silent network drop, until the keep-alive notices it. Against a
> real server with a refused node, a {{getOpcUaClient()}} call waited 9.8 s
> (see the review of [#28212|https://github.com/apache/camel/pull/28212]);
> * with a server that answers the keep-alives but not the service call, up to
> the request timeout (60 s by default).
> A write that sets a setpoint or sends a command then waits for unrelated
> subscription work on the same connection, for example another route that
> starts or stops.
> h3. Proposal
> The producer methods and {{getOpcUaClient()}} read the current connection
> without {{lock}} (a volatile field, still written under {{lock}}) and start
> their request as today. The subscription work keeps {{lock}}. Two things have
> to hold then:
> # {{Connected.dispose()}} sets {{client}} to null. A request on a connection
> that is disposed meanwhile has to complete exceptionally, not with a
> NullPointerException.
> # A failed request calls {{handleConnectionFailure}}, which tears down
> whatever connection is current. Without {{lock}} the failure may come from a
> connection that was replaced meanwhile, so it has to tear down only the
> connection the request was sent on.
> For the second point it is worth deciding first whether a failed request
> should tear the connection down at all: Milo reactivates a lost session
> itself, and since CAMEL-25835 the consumers are told about the loss. If it
> should not, the second point goes away.
> h3. Related
> CAMEL-25694 and CAMEL-25695
> ([#27956|https://github.com/apache/camel/pull/27956]) change the completion
> of the same four producer methods from {{handleAsync}} to
> {{whenCompleteAsync}}; this change would follow that one. Raised in the
> review of CAMEL-25692 ([#28212|https://github.com/apache/camel/pull/28212]).
> I can send a PR.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
