Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 76B4CF6F8 for ; Wed, 3 Apr 2013 21:29:28 +0000 (UTC) Received: (qmail 91110 invoked by uid 500); 3 Apr 2013 21:29:28 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 91049 invoked by uid 500); 3 Apr 2013 21:29:27 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 91041 invoked by uid 99); 3 Apr 2013 21:29:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 21:29:27 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 21:29:23 +0000 Received: by mail-ie0-f175.google.com with SMTP id c12so2297324ieb.34 for ; Wed, 03 Apr 2013 14:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=MHxJN9JjTHZ0a2nUm9KGppG5BsdLCfn9q4Ij563tBkU=; b=hLEmlEIgqQr3qlPXWNKtLyq9MDxeXfCEomN4su6R9EyGRXubRtXyQpJLq0lozJkqf0 lLvifjhd2p+BRv5zFcEGQUoVIt/nDSXMCv0HSKGgbSTLP9qN5ZO2fYFuWedFsk6K6Bmi Biw0Qdm8eR55NZkDmndSZauBUrrKTBSojcflOTS71giapy4/djcOkDr/aezlZt68qAj7 iCEtySeBsq9TSbjt4WYL4SEp21aoKbhdEabE9RxdnM1KhVeTlZDEYLdP0IXJOq9OR9bm 8D1aDNCQJn8+RmJkwYDt+PmGv6FLAnAtghGUdhDp92F/OmHATqwW8FAZLdmU/FNiPHRr hXAQ== MIME-Version: 1.0 X-Received: by 10.50.191.228 with SMTP id hb4mr2150189igc.37.1365024542963; Wed, 03 Apr 2013 14:29:02 -0700 (PDT) Received: by 10.64.7.35 with HTTP; Wed, 3 Apr 2013 14:29:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 22:29:02 +0100 Message-ID: Subject: Re: Question regaring maximumRedeliveries and ActiveMQMessageConsumer.java From: Gary Tully To: "users@activemq.apache.org" Content-Type: multipart/alternative; boundary=bcaec5396512fe3d6304d97b8ac1 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec5396512fe3d6304d97b8ac1 Content-Type: text/plain; charset=ISO-8859-1 redelivery is managed client side, the broker typically just fires out the message to a consumer and it is either acked or not. If there is a restart and the message was not acked it will be redelivered. There is an option to have kahadb rewrite the message to persist the delivery count https://issues.apache.org/jira/browse/AMQ-3519 such that even after a restart a redelivery will be visible in the deliveryCount property. The rollback: that is the result of a consumer that has a failover connection that has reconnected before the commit reply has been received. So the transaction has to be replayed. If the message is not again delivered to that consumer (it goes to some other consumer) then that transaction needs to be rolledback to indicate the failed original delivery. Please open an issue to track the fact that consumerFailoverRedeliveryWaitPeriod is not exposed. That value needs to exceed a redispatch but that should be immediate once the reconnect is complete. On 27 March 2013 19:50, Daniel Guggi wrote: > hi, > > version: activemq-5.8.0 > > we don't want client/consumer redelivery, so therefore we have set > maximumRedeliveries=0 on the connectionFactory > (ActiveMQConnectionFactory.java). Simple local (single-instance-broker) > tests verfied that no redelivery was performed. > > today we tried a simple failover scenario with a master/slave (shared > filesystem) environment using kahadb. > > we send one message to some queue (via web-console). > this message is received by a consumer with transacted-session and > connection.redeliveryPolicy.maxiumRedeliveries=0 > - during the message is processed (messagelistener.onmessage) we just > killed the master to see if the failover to the slave works correctly > > we noticed the following error in our log-files (but not always) > > Execution of > JMS message listener failed, and no ErrorHandler has been set. > javax.jms.TransactionRolledBackException: rolling back transaction > (TX:ID:blablabla-55731-136 > 4392340448-5:1:1) post failover recovery. 1 previously delivered message(s) > not replayed to consumer: ID:blablabla-55731-1364392340448-5:1:1:1 > > This message comes from ActiveMQMessageConsumer.java:1120 > > as far as I understand the code this should only happen if redeliveryPolicy > is > 0? (or do we have to set maximumRedelivery to -1 as the constant > RedeliveryPolicy.NO_MAXIMUM_REDELIVERIES states?) > > > Btw. there is a proptery "failoverRedeliveryWaitPeriod" in > ActiveMQMessageConsumer (we were shortly heading this direction because of > the "failover"-prefix :D). > This property is set in the constructor in line > 265: this.failoverRedeliveryWaitPeriod = > session.connection.getConsumerFailoverRedeliveryWaitPeriod(); > > However ActiveMQConnectionFactory.java does not provide this property, so > there it is not possible to set this property via ActiveMQConnectionFactory > -> eventually this might be a bug? If this property is supposed to be set > via the connectionFactory, then ActiveMQConnectionFactory.java should have: > > private long consumerFailoverRedeliveryWaitPeriod; > > public long getConsumerFailoverRedeliveryWaitPeriod() { > return consumerFailoverRedeliveryWaitPeriod; > } > > public void setConsumerFailoverRedeliveryWaitPeriod(long > consumerFailoverRedeliveryWaitPeriod) { > this.consumerFailoverRedeliveryWaitPeriod = > consumerFailoverRedeliveryWaitPeriod; > } > > protected void configureConnection(ActiveMQConnection connection) > throws JMSException { > .... > > > connection.setConsumerFailoverRedeliveryWaitPeriod(consumerFailoverRedeliveryWaitPeriod); > } > > public void populateProperties(Properties props) { > ... > props.setProperty("consumerFailoverRedeliveryWaitPeriod", > Long.toString(consumerFailoverRedeliveryWaitPeriod)); > } > > thank you, > daniel > -- http://redhat.com http://blog.garytully.com --bcaec5396512fe3d6304d97b8ac1--