You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2021/09/30 10:29:00 UTC

[jira] [Updated] (CAMEL-17022) camel-mina - MinaProducer does not disconnect on timeouts

     [ https://issues.apache.org/jira/browse/CAMEL-17022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-17022:
--------------------------------
    Summary: camel-mina - MinaProducer does not disconnect on timeouts  (was: MinaProducer does not disconnect on timeouts)

> camel-mina - MinaProducer does not disconnect on timeouts
> ---------------------------------------------------------
>
>                 Key: CAMEL-17022
>                 URL: https://issues.apache.org/jira/browse/CAMEL-17022
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-mina
>            Reporter: christian ohr
>            Priority: Major
>             Fix For: 3.11.3, 3.13.0
>
>
> This is basically a follow up on CAMEL-5404.
> If the "disconnect" parameter is *not* set on true, the same problem occurs as described in CAMEL-5404 in case of a timeout, i.e. a delayed response may be incorrectly associated with a subsequent request, which leads to disaster.
> To avoid this behavior, "disconnect" could be set to "true" - however, this would close the connection also after each response successfully delivered in time. This causes unnecessary overhead when reopening connections every time.
> Proposal:
> {code:java}
>         if (sync) {
>             // wait for response, consider timeout
>             LOG.debug("Waiting for response using timeout {} millis.", timeout);
>             boolean done = responseLatch.await(timeout, TimeUnit.MILLISECONDS);
>             if (!done) {
>                 # NEW: Force session to be closed on timeouts
>                 closeSessionIfNeededAndAwaitCloseInHandler(session);
>                 throw new ExchangeTimedOutException(exchange, timeout);
>             } {code}
> Maybe this behavior can also be tied to a producer-side disconnectOnNoReply parameter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)