You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by asafm <as...@gmail.com> on 2018/04/05 07:04:10 UTC

Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

I am using NMS ActiveMQ .NET client to pull messages from the queue using
MessageConsumer.ReceiveNoWait method.
The consumer application attempts to pull all pending messages every second.
I am trying to configure messages to be resent, but oddly it does not work
as expected.
I have tried using the configuration file of both consumer application and
broker (not both at once), and with each configuration the behavior is
slightly different, bot both behaviors are not as expected regarding the
configured values.

1. Configuration of consumer application
I have used the following URL:
"failover:(tcp://a.b.c.d:61616,tcp://e.f.g.h:61616)?
nested.jms.prefetchPolicy.all=50&amp;
nested.jms.redeliveryPolicy.maximumRedeliveries=5&amp;
nested.jms.redeliveryPolicy.useExponentialBackOff=true&amp;
nested.jms.redeliveryPolicy.backOffMultiplier=2&amp;
nested.jms.redeliveryPolicy.initialRedeliveryDelay=65000&amp;
nested.jms.redeliveryPolicy.maximumRedeliveryDelay=-1"

In this case each message was redelivered 5 times, once a second or two,
before being sent to DLQ, disregarding the other parameters. I have tried
other combinations such as useExponentialBackOff=false and
initialRedeliveryDelay=0 with redeliveryDelay=65000, with no improvement.

This behavior is problematic because sometimes it takes close to a minute to
handle a message, which will cause the message to be resent because the
consumer will not commit the session on time.

2. Configuration of ActiveMQ broker in activemq.xml file
I have used the following XML element under <broker>:
	<plugins>
            <redeliveryPlugin fallbackToDeadLetter="true"
                              sendToDlqIfMaxRetriesExceeded="true">
                <redeliveryPolicyMap>
                    <redeliveryPolicyMap>
                        <redeliveryPolicyEntries>
                            <redeliveryPolicy queue="xxx"
                                              maximumRedeliveries="2"
                                              redeliveryDelay="65000"/>
                        </redeliveryPolicyEntries>
                    </redeliveryPolicyMap>
                </redeliveryPolicyMap>
            </redeliveryPlugin>
        </plugins>

As a result, message was being pulled from the queue many times almost every
second, with one interval of 65 seconds. Here is a snippet from the consumer
log file, showing timestamps of pulling a specific message:
[2018-04-05 04:53:47,847]
[2018-04-05 04:53:47,847]
[2018-04-05 04:53:48,863]
[2018-04-05 04:53:48,863]
[2018-04-05 04:53:50,900]
[2018-04-05 04:53:50,900]
[2018-04-05 04:53:52,903]
[2018-04-05 04:53:52,904]
[2018-04-05 04:53:53,924]
[2018-04-05 04:53:53,924]
[2018-04-05 04:53:55,939]
[2018-04-05 04:53:55,939]
[2018-04-05 04:53:57,957]
[2018-04-05 04:53:57,957]
[2018-04-05 04:54:05,077]
[2018-04-05 04:54:05,077]
[2018-04-05 04:54:06,107]
[2018-04-05 04:54:06,107]
[2018-04-05 04:54:07,133]
[2018-04-05 04:54:07,133]
[2018-04-05 04:54:08,153]
[2018-04-05 04:54:08,153]
[2018-04-05 04:54:09,181]
[2018-04-05 04:54:09,181]
[2018-04-05 04:54:10,199]
[2018-04-05 04:54:10,199]
[2018-04-05 04:55:15,789]
[2018-04-05 04:55:15,789]
[2018-04-05 04:55:17,822]
[2018-04-05 04:55:17,822]
[2018-04-05 04:55:18,845]
[2018-04-05 04:55:18,845]
[2018-04-05 04:55:20,876]
[2018-04-05 04:55:20,876]
[2018-04-05 04:55:22,893]
[2018-04-05 04:55:22,893]

This behavior imposes a problem for our production environment, because it
will overload the consumer when message handling will fail.

All applications - producer, consumer and ActiveMQ broker are running on
Windows Server 2012 in Azure.
Any help will be greatly appreciated.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

Posted by asafm <as...@gmail.com>.
Update to the broker configuration:
After changing maximumRedeliveries to 4, messages did not get sent to the
DLQ after expiration time (4 minutes + 20 seconds), and just piled up in the
specific queue.
I have also forgot to mention that I am using the failover protocol for
master/slave configuration with two brokers.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

Posted by asafm <as...@gmail.com>.
Problem solved, thanks to Tim's help: 
I replaced jms & nested prefixes by nms prefix, and removed one property
that was not supported, and consumer-side configuration now works.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

Posted by asafm <as...@gmail.com>.
Thanks Tim.
Do you know of any references or examples that include configuration options
for message re-delivery?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Unexpected resend behavior when pulling messages using NMS .NET ReceiveNoWait

Posted by Timothy Bish <ta...@gmail.com>.
On 04/05/2018 03:04 AM, asafm wrote:
> I am using NMS ActiveMQ .NET client to pull messages from the queue using
> MessageConsumer.ReceiveNoWait method.
> The consumer application attempts to pull all pending messages every second.
> I am trying to configure messages to be resent, but oddly it does not work
> as expected.
> I have tried using the configuration file of both consumer application and
> broker (not both at once), and with each configuration the behavior is
> slightly different, bot both behaviors are not as expected regarding the
> configured values.
>
> 1. Configuration of consumer application
> I have used the following URL:
> "failover:(tcp://a.b.c.d:61616,tcp://e.f.g.h:61616)?
> nested.jms.prefetchPolicy.all=50&amp;
> nested.jms.redeliveryPolicy.maximumRedeliveries=5&amp;
> nested.jms.redeliveryPolicy.useExponentialBackOff=true&amp;
> nested.jms.redeliveryPolicy.backOffMultiplier=2&amp;
> nested.jms.redeliveryPolicy.initialRedeliveryDelay=65000&amp;
> nested.jms.redeliveryPolicy.maximumRedeliveryDelay=-1"

That doesn't look like an NMS.ActiveMQ client URI so I'd guess you'd 
want to start there.  The giveaway is the fact that I see JMS prefixes 
in there which aren't applicable to NMS clients, and also they are being 
set in nested values which would never be applied as those are top level 
URI options and not applicable to the IO transport.

http://activemq.apache.org/nms/activemq-uri-configuration.html

> In this case each message was redelivered 5 times, once a second or two,
> before being sent to DLQ, disregarding the other parameters. I have tried
> other combinations such as useExponentialBackOff=false and
> initialRedeliveryDelay=0 with redeliveryDelay=65000, with no improvement.
>
> This behavior is problematic because sometimes it takes close to a minute to
> handle a message, which will cause the message to be resent because the
> consumer will not commit the session on time.
>
> 2. Configuration of ActiveMQ broker in activemq.xml file
> I have used the following XML element under <broker>:
> 	<plugins>
>              <redeliveryPlugin fallbackToDeadLetter="true"
>                                sendToDlqIfMaxRetriesExceeded="true">
>                  <redeliveryPolicyMap>
>                      <redeliveryPolicyMap>
>                          <redeliveryPolicyEntries>
>                              <redeliveryPolicy queue="xxx"
>                                                maximumRedeliveries="2"
>                                                redeliveryDelay="65000"/>
>                          </redeliveryPolicyEntries>
>                      </redeliveryPolicyMap>
>                  </redeliveryPolicyMap>
>              </redeliveryPlugin>
>          </plugins>
>
> As a result, message was being pulled from the queue many times almost every
> second, with one interval of 65 seconds. Here is a snippet from the consumer
> log file, showing timestamps of pulling a specific message:
> [2018-04-05 04:53:47,847]
> [2018-04-05 04:53:47,847]
> [2018-04-05 04:53:48,863]
> [2018-04-05 04:53:48,863]
> [2018-04-05 04:53:50,900]
> [2018-04-05 04:53:50,900]
> [2018-04-05 04:53:52,903]
> [2018-04-05 04:53:52,904]
> [2018-04-05 04:53:53,924]
> [2018-04-05 04:53:53,924]
> [2018-04-05 04:53:55,939]
> [2018-04-05 04:53:55,939]
> [2018-04-05 04:53:57,957]
> [2018-04-05 04:53:57,957]
> [2018-04-05 04:54:05,077]
> [2018-04-05 04:54:05,077]
> [2018-04-05 04:54:06,107]
> [2018-04-05 04:54:06,107]
> [2018-04-05 04:54:07,133]
> [2018-04-05 04:54:07,133]
> [2018-04-05 04:54:08,153]
> [2018-04-05 04:54:08,153]
> [2018-04-05 04:54:09,181]
> [2018-04-05 04:54:09,181]
> [2018-04-05 04:54:10,199]
> [2018-04-05 04:54:10,199]
> [2018-04-05 04:55:15,789]
> [2018-04-05 04:55:15,789]
> [2018-04-05 04:55:17,822]
> [2018-04-05 04:55:17,822]
> [2018-04-05 04:55:18,845]
> [2018-04-05 04:55:18,845]
> [2018-04-05 04:55:20,876]
> [2018-04-05 04:55:20,876]
> [2018-04-05 04:55:22,893]
> [2018-04-05 04:55:22,893]
>
> This behavior imposes a problem for our production environment, because it
> will overload the consumer when message handling will fail.
>
> All applications - producer, consumer and ActiveMQ broker are running on
> Windows Server 2012 in Azure.
> Any help will be greatly appreciated.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/