You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Teemu Torma (JIRA)" <ji...@apache.org> on 2009/07/22 01:23:33 UTC
[jira] Updated: (AMQCPP-256) Transaction has not been started
exceptions on the broker with parallel transacted sessions
[ https://issues.apache.org/activemq/browse/AMQCPP-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Teemu Torma updated AMQCPP-256:
-------------------------------
Attachment: mt-receive.cpp
Here is a test program, I hope it is clear enough. I haven't tried with 5.3, but even with 5.2 this works with activemq-cpp 2.2.
The usage is to send let's say 100 messages to queue FOO and then run the program. What I see is broker exceptions and even if I receive exactly 100 messages, something might be left at the server.
The behaviour is a bit random and may not be reproducible at every run, but currently this fails for me every time if there are 100 messages in the queue at localhost.
> Transaction has not been started exceptions on the broker with parallel transacted sessions
> -------------------------------------------------------------------------------------------
>
> Key: AMQCPP-256
> URL: https://issues.apache.org/activemq/browse/AMQCPP-256
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: Ubuntu Jaunty 9.04
> Reporter: Teemu Torma
> Assignee: Timothy Bish
> Priority: Critical
> Attachments: mt-receive.cpp
>
>
> When using parallel transacted sessions and consumers to same queue each sharing the same connection, the messages are delivered but the broker 5.2 gets exceptions
> javax.jms.JMSException: Transaction 'TX:de411476-d65d-fff7-1e84-be7c9abd80b5:6' has not been started.
> and some messages are left on the broker even though they were delivered.
> The issue seems to be related to multi-threading, by protecting each receive/commit with a lock the error does not happen. I am sorry I don't have a test program ready, but it should be easy to reproduce by creating multiple transacted session threads with prefetchSize=1 and consuming messages, commiting after each message. I have seen this happen both with consumers and listeners.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.