[prev in list] [next in list] [prev in thread] [next in thread]
List: activemq-dev
Subject: [jira] Commented: (AMQ-1845) Message loss in network of brokers
From: "Gary Tully (JIRA)" <jira () apache ! org>
Date: 2008-07-29 13:30:01
Message-ID: 917653867.1217338201240.JavaMail.jira () brutus
[Download RAW message or body]
[ https://issues.apache.org/activemq/browse/AMQ-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44605#action_44605 \
]
Gary Tully commented on AMQ-1845:
---------------------------------
The problem is that the consumer uses a transacted session but does not commit the \
transaction. If you examine the consumer broker using the jmx/jconsole, you will see \
that the queue has all its messages inflight, delivered but not acked. They won't be \
committed till the transaction associated with the cached consumer session is \
committed.
Spring jms template does quite a bit of work under the hood, it may may make sense to \
strip your test application down to pure jms api calls. In any event, to proceed \
further with your testing, for your test consumer DefaultMessageListenerContainer \
configuration use the following: {code}
<bean id="listenerContainer" \
class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property \
name="connectionFactory" ref="jmsFactory" /> <property name="destinationName" \
value="test-out" /> <property name="messageListener" ref="listener" />
<property name="sessionTransacted" value="false" />
</bean>
{code}
That is, do not use a transacted session. (Or stick with a transacted session but \
commit the transaction in your listener via session.commit or via the springjms \
prescribed way.)
> Message loss in network of brokers when network connection break
> ----------------------------------------------------------------
>
> Key: AMQ-1845
> URL: https://issues.apache.org/activemq/browse/AMQ-1845
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.1.0
> Environment: Two brokers connected via TCP with one persistent distributed queue \
> and a producer and a consumer on each broker.
> Reporter: Bryan Shaw
> Assignee: Gary Tully
>
> Producer on broker A send 2500 message on the distributed queue at broker A.
> Producer B starts to receive message from distributed queue on broker B.
> During the receiving process, the network between these two brokers down and later \
> brought up again. In this senario, we found that some messages are lost.
> It seems the broker A are sending message to broker B when the network is down and \
> these messages are removed from queue in broker A but never received by broker B \
> which causing message loss. Is this a bug or a configuration problem?
> I thought the configuration like this is the store/forward pattern which should \
> ensure the message reliability in an unstable network.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic