Hmmm, that’s really weird. SchedulerSupport is enabled on the broker ?

Let me try to reproduce. I keep you posted.

Regards
JB

> Le 31 janv. 2021 à 16:54, Martin Lichtin <lich...@yahoo.com.INVALID> a écrit :
> 
> There's no exception, but the re-delivery no longer works.
> It's a server-side redelivery case, configuring the broker with the 
> redeliveryPlugin, such as:
> 
>       <redeliveryPlugin fallbackToDeadLetter="true" 
> sendToDlqIfMaxRetriesExceeded="true">
>         <redeliveryPolicyMap>
>           <redeliveryPolicyMap>
>             <redeliveryPolicyEntries>
>               <redeliveryPolicy queue="TEST.>" maximumRedeliveries="5" 
> initialRedeliveryDelay="2000" redeliveryDelay="2000" />
>             </redeliveryPolicyEntries>
>           </redeliveryPolicyMap>
>         </redeliveryPolicyMap>
>       </redeliveryPlugin>
> 
> then consuming a message from a 'TEST.abc' queue, the test code throwing an 
> exception to let it go back to server so it gets redelivered after 2 seconds. 
> With 5.16.1 this no longer works, as the re-delivery is for some reason is 
> considered a duplicate and suppressed.
> The logs:
> 
>        RedeliveryPlugin  175 | 40 - org.apache.activemq.activemq-osgi - 
> 5.16.1 | redelivery #1 of: ID:mlipc2-4159-1611768583683-1:15:1:1:41 with 
> delay: 1000, dest: queue://TEST.msgin
> ActiveMQMessageConsumer 1485 | 40 - org.apache.activemq.activemq-osgi - 
> 5.16.1 | ID:mlipc2-4159-1611768583683-1:16:1:1 suppressing duplicate delivery 
> on connection, poison acking: MessageDispatch {commandId = 0, 
> responseRequired = false, consumerId = ID:mlipc2-4159-1611768583683-1:16:1:1, 
> destination = queue://TEST.msgin, message = ActiveMQTextMessage {commandId = 
> 125, responseRequired = true, messageId = 
> ID:mlipc2-4159-1611768583683-1:15:1:1:41, originalDestination = null, 
> originalTransactionId = null, producerId = 
> ID:mlipc2-4159-1611768583683-1:15:1:1, destination = queue://TEST.msgin, 
> transactionId = null, expiration = 0, timestamp = 1611768605501, arrival = 0, 
> brokerInTime = 1611768607001, brokerOutTime = 1611768607012, correlationId = 
> null, replyTo = null, persistent = true, type = null, priority = 0, groupID = 
> null, groupSequence = 0, targetConsumerId = null, compressed = false, userID 
> = null, content = org.apache.activemq.util.ByteSequence@5f105a66, 
> marshalledProperties = org.apache.activemq.util.ByteSequence@5b2fd55c, 
> dataStructure = null, redeliveryCounter = 1, size = 0, properties = 
> {redeliveryDelay=2000, 
> scheduledJobId=ID:mlipc2-4159-1611768583683-1:15:1:1:2}, readOnlyProperties = 
> true, readOnlyBody = true, droppable = false, jmsXGroupFirstForConsumer = 
> false, text = XXX}, redeliveryCounter = 1}
> 
> Of course it is a duplicate, but JMSRedelivered will be set to true, and 
> another header tells the consumer the redelivery count.
> Any version before 5.16.0, this works fine and the "suppressing duplicate" 
> does not occur.
> 
> - Martin
> 
> On 27.01.2021 19:24, Jean-Baptiste Onofre wrote:
>> Hi Martin,
>> 
>> Do you have some exception ?
>> 
>> Let me try it on 5.16.1 (I didn’t see any issue but I might have missed it).
>> 
>> Regards
>> JB
>> 
>>> Le 27 janv. 2021 à 18:41, Martin Lichtin <lich...@yahoo.com.INVALID> a 
>>> écrit :
>>> 
>>> Hi, has anything changed regarding server-side redelivery using the 
>>> <redeliveryPlugin>?
>>> 
>>> Going from 5.15.14 to 5.16.1, it seems to no longer work as expected.
>>> 
>>> I see AMQ-7298 which may contribute to a change in this area.
>>> 
>>> - Martin
>>> 
>>> 
>> 

Reply via email to