[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