[
https://issues.apache.org/jira/browse/QPIDJMS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488158#comment-17488158
]
Robbie Gemmell commented on QPIDJMS-563:
----------------------------------------
For failover to be happening at all and for the described behaviour to occur,
it sounds more like the _connection_ is being erroneously terminated by the
server while it is 'rejecting' the message, and that it is not actually
_rejecting the message_ as such at all. This really isnt expected protocol
behaviour and rather defeats the point of being able to [n]ack the message
itself (where actually rejected would probably be the wrong state to use as
that is intended to mean the message is malformed, a modified-failed
disposition to indicate deliver failure would probably be a more suited for the
described cases). I'd suggest confirming what is actually happening via the
protocol trace log
[https://qpid.apache.org/releases/qpid-jms-1.5.0/docs/index.html#logging] and
perhaps even other general trace/debug.
Meanwhile, assuming that is the case, since the new connection created _has_
actually _succeeded_ in being created and senders etc been reestablished to get
to the point of a send occurring, the reconnect counter is reset and work using
the connection then continues, which leads to the send. The
maxReconnectAttempts thus has no effect in limiting this odd scenario, since
the _new_ underlying connection going down begins a fresh reconnect cycle which
naturally has its own maxReconnectAttempts. In general there is no 'send
retries counting' as the client does not generally resend (failover is the only
instance it ever can) and even then sending is really considered _outwith_ the
connection process and sends are expected to succeed/fail individually and not
in the manner it seems may be getting used here of killing the whole connection.
> QPID JMS - Failover - endless loop on sending a message with reject outcome
> ---------------------------------------------------------------------------
>
> Key: QPIDJMS-563
> URL: https://issues.apache.org/jira/browse/QPIDJMS-563
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 1.5.0
> Reporter: Thomas Stollenwerk
> Priority: Critical
>
> +*Summary:*+
> Having a amqp v1 message which is rejected by the amqp v1 broker results in
> an endless failover loop blocking the JmsMessageProducer.send method.
> +*Expected:*+
> The failover of the qpid jms client tries to connect and send the rejected
> message in a maximum of failover.maxReconnectAttempts.
> +*Actual:*+
> The result of the message send task is not taken into account for counting
> the attempts.
> The JmsMessageProducer.send gets stuck forever.
> # Failover connects to the failover uri and then resets the attempt counter.
> # Sending the message results in REJECT outcome.
> # Failover connects to the next failover uri and then resets the attempt
> counter.
> # Sending the message results in REJECT outcome.
> # ... repeats and does not stop on maxReconnectAttempts.
> +*Code analysis:*+
> *FailoverProvider.java#L1282* already resets the connection attempts with
> *reconnectControl.connectionEstablished()* not waiting for the success of the
> send task, resulting in an endless failover loop.
> +*Background:*+
> In our case we are using RabbitMQ with the amqp v1 plugin. There are
> scenarios where the broker is answering with REJECT outcomes (overflow
> policy, high watermark etc). Right now we cannot use this feature because the
> client is stuck and the RabbitMQ is flooded with reconnects.
> We would be very grateful having a fix.
> Thanks for the good work and best regards
> Thomas
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
