[
https://issues.apache.org/activemq/browse/AMQ-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49029#action_49029
]
Frank E. Banks commented on AMQ-2089:
-------------------------------------
Hi Gary,
Unfortunately I think I spoke to soon. When I came in this morning I got a
bunch of jetty errors when attempting to access the Web admin. A look in the
logs revealed a bunch of errors on both our master and slave (we use the pure
master slave setup). Basically they seem to do with async errors on the slave.
It looks as if the acks on the session commit are the problem. I'll have more
details later, but for now I've reverted to the old code-which you essentially
have in the test case- which was at least stable.
Apparently it's only an issue with a master/slave setup, but I don't know for
sure. I'll have to do some more tests and get back to you.
> Transacted Messages Not Committed
> ---------------------------------
>
> Key: AMQ-2089
> URL: https://issues.apache.org/activemq/browse/AMQ-2089
> Project: ActiveMQ
> Issue Type: Test
> Components: Broker
> Affects Versions: 5.2.0
> Environment: linux centOS 64 bit, JRE 1.6.0_11-b03
> Reporter: Frank E. Banks
> Assignee: Gary Tully
> Fix For: 5.2.0
>
> Attachments: AMQWorkerTest.java, TestCase.java
>
>
> The basic architecture of the consumer is a java daemon that spawns a
> configurable number of single threaded consumers that implement
> MessageListener- each opens its own connection and transacted session. In
> the consumer onMessage() method session.commit() is being called upon
> successful processing of the message- and I've verified that it is actually
> executed. The problem is that despite the message being successfully
> processed and session.commit() executed the messages remain as pending in the
> queue. If the consumer daemon is stopped and re-started these messages are
> consumed again (definitely not good). Note that session.rollback() was NOT
> called in this scenario, all the messages were processed successfully. Also
> note that these are persistent messages and we are using the default AMQ
> message store.
> - The problem *only* occurs when the number of consumer threads is greater
> than 1.
> - The problem occurs whether or not a correlation ID is used on the messages.
> I wasn't sure if this mattered or not, but it doesn't.
> Fortunately, as a result of working with this test case I discovered a work
> around to the problem, which is to not only call session.commit() on
> successful message processing but to then call message.acknowledge() as well.
> This works like a charm, but it was my understanding that calling
> message.acknowledge() was not necessary when using transacted sessions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
