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 <daniel.gu...@gmail.com> 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
