Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 7 Feb 2013 00:04:14 +0000 (UTC)
From: "Rob Waite (JIRA)" <jira+amqnet@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12631167.1360195286575.257011.1360195454037@arcas>
In-Reply-To: <JIRA.12631167.1360195286575@arcas>
References: <JIRA.12631167.1360195286575@arcas>
Subject: [jira] [Updated] (AMQNET-410)
 jms.redeliveryPolicy.nonBlockingRedelivery=true not honored by NMS.ActiveMQ
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rob Waite updated AMQNET-410:
-----------------------------

    Description: 
Our system relies on redelivery. We realized that redelivery was performed by the client when we saw consumers appear to slow down or get stuck.

With ActiveMQ 5.6.0, jms.redeliveryPolicy.nonBlockingRedelivery was added to allow the client side redelivery to move forward instead of fully handling a particular message's redelivery before moving to other messages.

We realized that it was not implemented in NMS and ended up upgrading to ActiveMQ 5.7.0 which supports server-side redelivery using the Scheduler.

Seems fairly minor and may take a larger effort to implement this, judging from what it would likely do. It also seems that server-side is preferable to client-side anyway so maybe the nonBlockingRedelivery option was just a stop-gap until server-side was implemented.

Perhaps just logging a warning if it is used so it is easier to determine that it is not supported.

  was:
Our system relies on redelivery. We realized that redelivery was performed by the client when we saw consumers appear to slow down or get stuck.

With ActiveMQ 5.6.0, jms.redeliveryPolicy.nonBlockingRedelivery was added to allow the client side redelivery to move forward instead of fully handling a particular message's redelivery before moving to other messages.

We realized that it was not implemented in NMS and ended up upgrading to ActiveMQ 5.7.0 which supports server-side redelivery using the Scheduler.

Seems fairly minor and may take a larger effort to implement this, judging from what it would likely do.

    
> jms.redeliveryPolicy.nonBlockingRedelivery=true not honored by NMS.ActiveMQ
> ---------------------------------------------------------------------------
>
>                 Key: AMQNET-410
>                 URL: https://issues.apache.org/jira/browse/AMQNET-410
>             Project: ActiveMQ .Net
>          Issue Type: New Feature
>          Components: ActiveMQ
>    Affects Versions: 1.5.6
>         Environment: Any
>            Reporter: Rob Waite
>            Assignee: Jim Gomes
>            Priority: Minor
>
> Our system relies on redelivery. We realized that redelivery was performed by the client when we saw consumers appear to slow down or get stuck.
> With ActiveMQ 5.6.0, jms.redeliveryPolicy.nonBlockingRedelivery was added to allow the client side redelivery to move forward instead of fully handling a particular message's redelivery before moving to other messages.
> We realized that it was not implemented in NMS and ended up upgrading to ActiveMQ 5.7.0 which supports server-side redelivery using the Scheduler.
> Seems fairly minor and may take a larger effort to implement this, judging from what it would likely do. It also seems that server-side is preferable to client-side anyway so maybe the nonBlockingRedelivery option was just a stop-gap until server-side was implemented.
> Perhaps just logging a warning if it is used so it is easier to determine that it is not supported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira