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.