[
https://issues.apache.org/jira/browse/CAMEL-26112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serdar Gökay reassigned CAMEL-26112:
------------------------------------
Assignee: Serdar Gökay
> camel-milo - handleConnectionFailure disconnects the failed client while it
> holds the manager lock
> --------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26112
> URL: https://issues.apache.org/jira/browse/CAMEL-26112
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Affects Versions: 4.23.0
> Reporter: Serdar Gökay
> Assignee: Serdar Gökay
> Priority: Minor
>
> Follow-up of CAMEL-25912, named there as not done.
> {{SubscriptionManager.handleConnectionFailure()}} disposes the failed
> connection under the single manager lock, and the dispose calls
> {{OpcUaClient.disconnect()}}, which sends CloseSession and waits for the
> answer. During a silent drop of the link that call blocks until the request
> times out, and every caller of the lock waits with it: a consumer that starts
> or stops, and the subscription recovery itself. Since CAMEL-25912 the
> producers and {{MiloClientConnection.getOpcUaClient()}} no longer take the
> lock, so only the subscription work after a consumer-side failure still waits.
> Moving the disconnect out of the lock is not a small change:
> {{whenConnected()}} (under {{registerItems}} and {{unregisterItems}}),
> {{recreateSubscription()}} and {{recoverSubscription()}} call
> {{handleConnectionFailure()}} while they already hold the lock, so they would
> have to hand the failed connection out of their own lock scope, with a check
> that the connection they disconnect is still the one that failed. An
> asynchronous disconnect would instead occupy the single {{MiloClient}} or
> {{MiloClientReconnect}} thread on a machine with one processor. This issue is
> for choosing between these options and implementing one.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
