You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by jo...@offilive.com on 2018/06/02 11:41:02 UTC
qpid-jms: How to get message rejection/redelivery work correctly
Hi,
we are using the qpid-jms client with Artemis 2.6. I am having big troubles getting message rejection/redelivery working as expected. I already opened an issue against Artemis https://issues.apache.org/jira/browse/ARTEMIS-1618 (https://issues.apache.org/jira/browse/ARTEMIS-1618)but the more I play around with my test case the more I wonder if it may be an issue in qpid-jms itself.
What I am basically looking for is to consume messages with a MessageListener where in case of an unexpected error during message processing the onMessage() method throws a runtime exception that eventually signals to the broker that the message was not acknowledged. The broker then should try to redeliver the message 3 times and then put it into a pre-configured DLQ.
I played around with all kind combination of session modes incl. qpid-jms specific ones and different qpid-jms redeliveryPolicy settings but I am not getting any further. For example when I set the session mode to AUTO_ACKNOWLEDGE in qpid-jms, the message seems to be redelivered locally indefinitely. When I use any other session mode the message is not consumed a second time.
The Artemis JIRA issue contains a simple unit test case that can be used to easily reproduce the problem I am having. https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java (https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java)
I would really appreciate if someone could have a look at it and give me a hint on whether this looks like a bug/limitation in qpid-jms, or if I am doing something completely wrong, or if it seems to be a broker implementation issue.
Thanks!
Regards,
Johan
Re: qpid-jms: How to get message rejection/redelivery work correctly
Posted by Robbie Gemmell <ro...@gmail.com>.
Glas to hear things worked as expected when used as intended.
Your expectations on the second case were incorrect. Setting the
client side 'maxRedeliveries' to 0 specifically will never result in
the redelivery policy being enforced if the client 'releases' the
message to the server, since as I mentioned that does not increment
the AMQP message delivery count, which is what the consumer will base
its redelivery policy decision on when the message arrives next before
handing it to the application as the policy hasnt been exceeded. The
'outcome' configuration should make no difference in that case as no
outcome ever gets applied due to redelivery policy specifically since
it isnt breached.
Feel free to raise a JIRA for the behaviour on throwing from onMessage.
Robbie
On 2 June 2018 at 21:32, <jo...@offilive.com> wrote:
> When I am using session.recover() client side redelivery/message rejection works.
>
> What doesn't seem to work is that in Artemis is a server-side max-delivery-attempt value can be specified.
> So I expected if I set "jms.redeliveryPolicy.maxRedeliveries" on the client side to 0 and the "jms.redeliveryPolicy.outcome" to "RELEASE" the broker would then only attempts redeliver the message to the client as specified by max-delivery-attempt and then put it into the DLQ. However Artemis still infinitely tries to redeliver the message.
>
> Is it worth opening a bug report regarding qpid-jms's behavior to not increment delivery count
> in case a message listener throws a runtime exception?
>
> June 2, 2018 7:52 PM, "Robbie Gemmell" <ro...@gmail.com> wrote:
>
>> If you use session.recover() as intended, instead of letting onMessage
>> throw in error, then you might find it starts behaving in line with
>> expectation.
>>
>> When onMessage throws in error for auto-ack, it seems the client is
>> currently 'releasing' the delivery to ensure it doesnt get stuck in
>> limbo, however that doesnt cause its AMQP delivery count to be
>> incremented. It should perhaps instead send a 'modified, failed'
>> disposition if the peer indicated it was supported, which would result
>> in the delivery count being incremented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-jms: How to get message rejection/redelivery work
correctly
Posted by jo...@offilive.com.
When I am using session.recover() client side redelivery/message rejection works.
What doesn't seem to work is that in Artemis is a server-side max-delivery-attempt value can be specified.
So I expected if I set "jms.redeliveryPolicy.maxRedeliveries" on the client side to 0 and the "jms.redeliveryPolicy.outcome" to "RELEASE" the broker would then only attempts redeliver the message to the client as specified by max-delivery-attempt and then put it into the DLQ. However Artemis still infinitely tries to redeliver the message.
Is it worth opening a bug report regarding qpid-jms's behavior to not increment delivery count
in case a message listener throws a runtime exception?
June 2, 2018 7:52 PM, "Robbie Gemmell" <ro...@gmail.com> wrote:
> If you use session.recover() as intended, instead of letting onMessage
> throw in error, then you might find it starts behaving in line with
> expectation.
>
> When onMessage throws in error for auto-ack, it seems the client is
> currently 'releasing' the delivery to ensure it doesnt get stuck in
> limbo, however that doesnt cause its AMQP delivery count to be
> incremented. It should perhaps instead send a 'modified, failed'
> disposition if the peer indicated it was supported, which would result
> in the delivery count being incremented.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-jms: How to get message rejection/redelivery work correctly
Posted by Robbie Gemmell <ro...@gmail.com>.
If you use session.recover() as intended, instead of letting onMessage
throw in error, then you might find it starts behaving in line with
expectation.
When onMessage throws in error for auto-ack, it seems the client is
currently 'releasing' the delivery to ensure it doesnt get stuck in
limbo, however that doesnt cause its AMQP delivery count to be
incremented. It should perhaps instead send a 'modified, failed'
disposition if the peer indicated it was supported, which would result
in the delivery count being incremented.
On 2 June 2018 at 16:42, <jo...@offilive.com> wrote:
> Hi Tim,
>
> thanks for your response. The JMS spec states: "It is possible for a listener to throw a RuntimeException; however, this is
> considered a client programming error. ... The result of a listener throwing a RuntimeException depends on the session’s acknowledgment mode.
> - AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. The number of times a JMS provider will
> redeliver the same message before giving up is provider-dependent. The 'JMSRedelivered' message header field will be set, and the 'JMSXDeliveryCount' message property incremented, for a message redelivered under these circumstances."
>
> So, while it may be considered bad practice to throw an exception in a listener, the JMS provider behavior is specified for that case to a certain degree.
>
> For qpid-jms however, when I set the session mode to AUTO_ACKNOWLEDGE then a message is redelivered endlessly to the message listener and neither the "JMSRedelivered" nor the "JMSXDeliveryCount" header field are set. I also set "jms.redeliveryPolicy.maxRedeliveries=3" in the URI with no effect.
>
> Regards,
> Seb
>
> June 2, 2018 4:32 PM, "Timothy Bish" <ta...@gmail.com> wrote:
>
>> On 06/02/2018 07:41 AM, jo.stenberg@offilive.com wrote:
>>
>>> Hi,
>>>
>>> we are using the qpid-jms client with Artemis 2.6. I am having big troubles getting message
>>> rejection/redelivery working as expected. I already opened an issue against Artemis
>>> https://issues.apache.org/jira/browse/ARTEMIS-1618
>>> (https://issues.apache.org/jira/browse/ARTEMIS-1618)but the more I play around with my test case
>>> the more I wonder if it may be an issue in qpid-jms itself.
>>>
>>> What I am basically looking for is to consume messages with a MessageListener where in case of an
>>> unexpected error during message processing the onMessage() method throws a runtime exception that
>>> eventually signals to the broker that the message was not acknowledged. The broker then should try
>>> to redeliver the message 3 times and then put it into a pre-configured DLQ.
>>>
>>> I played around with all kind combination of session modes incl. qpid-jms specific ones and
>>> different qpid-jms redeliveryPolicy settings but I am not getting any further. For example when I
>>> set the session mode to AUTO_ACKNOWLEDGE in qpid-jms, the message seems to be redelivered locally
>>> indefinitely. When I use any other session mode the message is not consumed a second time.
>>>
>>> The Artemis JIRA issue contains a simple unit test case that can be used to easily reproduce the
>>> problem I am having.
>>> https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java
>>> (https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java)
>>>
>>> I would really appreciate if someone could have a look at it and give me a hint on whether this
>>> looks like a bug/limitation in qpid-jms, or if I am doing something completely wrong, or if it
>>> seems to be a broker implementation issue.
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Johan
>>
>> The JMS specification defines that an exception thrown from onMessage is a programming error, so
>> I'd say first thing to do is not do that any more and go from there. The behavior you want sounds
>> like a good candidate for a transacted Session with configuration on the redelivery policy that
>> controls how many deliveries to allow before the message is no longer allowed to be redelivered.
>>
>> Documentation on the redelivery policy for the Qpid JMS client is here.
>>
>> http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#jms-configuration-options
>>
>> -- Tim Bish
>> twitter: @tabish121
>> blog: http://timbish.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-jms: How to get message rejection/redelivery work
correctly
Posted by jo...@offilive.com.
Hi Tim,
thanks for your response. The JMS spec states: "It is possible for a listener to throw a RuntimeException; however, this is
considered a client programming error. ... The result of a listener throwing a RuntimeException depends on the session’s acknowledgment mode.
- AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. The number of times a JMS provider will
redeliver the same message before giving up is provider-dependent. The 'JMSRedelivered' message header field will be set, and the 'JMSXDeliveryCount' message property incremented, for a message redelivered under these circumstances."
So, while it may be considered bad practice to throw an exception in a listener, the JMS provider behavior is specified for that case to a certain degree.
For qpid-jms however, when I set the session mode to AUTO_ACKNOWLEDGE then a message is redelivered endlessly to the message listener and neither the "JMSRedelivered" nor the "JMSXDeliveryCount" header field are set. I also set "jms.redeliveryPolicy.maxRedeliveries=3" in the URI with no effect.
Regards,
Seb
June 2, 2018 4:32 PM, "Timothy Bish" <ta...@gmail.com> wrote:
> On 06/02/2018 07:41 AM, jo.stenberg@offilive.com wrote:
>
>> Hi,
>>
>> we are using the qpid-jms client with Artemis 2.6. I am having big troubles getting message
>> rejection/redelivery working as expected. I already opened an issue against Artemis
>> https://issues.apache.org/jira/browse/ARTEMIS-1618
>> (https://issues.apache.org/jira/browse/ARTEMIS-1618)but the more I play around with my test case
>> the more I wonder if it may be an issue in qpid-jms itself.
>>
>> What I am basically looking for is to consume messages with a MessageListener where in case of an
>> unexpected error during message processing the onMessage() method throws a runtime exception that
>> eventually signals to the broker that the message was not acknowledged. The broker then should try
>> to redeliver the message 3 times and then put it into a pre-configured DLQ.
>>
>> I played around with all kind combination of session modes incl. qpid-jms specific ones and
>> different qpid-jms redeliveryPolicy settings but I am not getting any further. For example when I
>> set the session mode to AUTO_ACKNOWLEDGE in qpid-jms, the message seems to be redelivered locally
>> indefinitely. When I use any other session mode the message is not consumed a second time.
>>
>> The Artemis JIRA issue contains a simple unit test case that can be used to easily reproduce the
>> problem I am having.
>> https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java
>> (https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java)
>>
>> I would really appreciate if someone could have a look at it and give me a hint on whether this
>> looks like a bug/limitation in qpid-jms, or if I am doing something completely wrong, or if it
>> seems to be a broker implementation issue.
>>
>> Thanks!
>>
>> Regards,
>> Johan
>
> The JMS specification defines that an exception thrown from onMessage is a programming error, so
> I'd say first thing to do is not do that any more and go from there. The behavior you want sounds
> like a good candidate for a transacted Session with configuration on the redelivery policy that
> controls how many deliveries to allow before the message is no longer allowed to be redelivered.
>
> Documentation on the redelivery policy for the Qpid JMS client is here.
>
> http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#jms-configuration-options
>
> -- Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: qpid-jms: How to get message rejection/redelivery work correctly
Posted by Timothy Bish <ta...@gmail.com>.
On 06/02/2018 07:41 AM, jo.stenberg@offilive.com wrote:
> Hi,
>
> we are using the qpid-jms client with Artemis 2.6. I am having big troubles getting message rejection/redelivery working as expected. I already opened an issue against Artemis https://issues.apache.org/jira/browse/ARTEMIS-1618 (https://issues.apache.org/jira/browse/ARTEMIS-1618)but the more I play around with my test case the more I wonder if it may be an issue in qpid-jms itself.
>
> What I am basically looking for is to consume messages with a MessageListener where in case of an unexpected error during message processing the onMessage() method throws a runtime exception that eventually signals to the broker that the message was not acknowledged. The broker then should try to redeliver the message 3 times and then put it into a pre-configured DLQ.
>
> I played around with all kind combination of session modes incl. qpid-jms specific ones and different qpid-jms redeliveryPolicy settings but I am not getting any further. For example when I set the session mode to AUTO_ACKNOWLEDGE in qpid-jms, the message seems to be redelivered locally indefinitely. When I use any other session mode the message is not consumed a second time.
>
> The Artemis JIRA issue contains a simple unit test case that can be used to easily reproduce the problem I am having. https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java (https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java)
>
> I would really appreciate if someone could have a look at it and give me a hint on whether this looks like a bug/limitation in qpid-jms, or if I am doing something completely wrong, or if it seems to be a broker implementation issue.
>
> Thanks!
>
> Regards,
> Johan
>
The JMS specification defines that an exception thrown from onMessage is
a programming error, so I'd say first thing to do is not do that any
more and go from there. The behavior you want sounds like a good
candidate for a transacted Session with configuration on the redelivery
policy that controls how many deliveries to allow before the message is
no longer allowed to be redelivered.
Documentation on the redelivery policy for the Qpid JMS client is here.
http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#jms-configuration-options
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org