Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <1854520847.1258745272930.JavaMail.jira@brutus>
Date: Fri, 20 Nov 2009 11:27:52 -0800 (PST)
From: "Bruce Snyder (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-1295) Message lost and duplication with
 multiple consumers
In-Reply-To: <17231785.1182867932923.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/activemq/browse/AMQ-1295?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Snyder updated AMQ-1295:
------------------------------

    Fix Version/s:     (was: AGING_TO_DIE)
                   5.4.0

> Message lost and duplication with multiple consumers
> ----------------------------------------------------
>
>                 Key: AMQ-1295
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1295
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.0.0
>         Environment: Standalone broker, Oracle JDBC, no journal persisten=
ce.
>            Reporter: Manuel Teira
>             Fix For: 5.4.0
>
>         Attachments: JMSTestCP.java, planb.xml
>
>
> Not sure about the exact conditions triggering this bug, but I was able t=
o reproduce it multiple times using the attached client. What the client do=
es is:
> -Opens a connection.
> -Creates a configurable number of threads to play the role of consumers i=
n a given queue.
>     -The consumer creates a transacted session and fetches messages using=
 a JMSConsumer.
> -Creates a configurable number of threads to play the role of producers i=
n the given queue.
>     -Every consumer sends a given amount of messages to the queue, openin=
g a AUTO_ACKNOWLEDGE session and a JMSProducer to send them.
> The bug was detected running two clients simultaneously, with the configu=
ration:
> - 1 Producer
> - 10 Consumers
> - 1000 Messages
> Sometimes one or two messages weren't delivered to the consumers. Running=
 a new client on the same queue didn't help. The only way to get the "froze=
n" messages delivered was restarting the browser.
> On other situations, some message was delivered twice. This was seen as t=
he JMX console reported a queuesize =3D -2, and dequeuecount =3D enqueuecou=
nt + 2. Also, a counter in the client  updated for every received message s=
hown the wrong count of messages.=C3=A7
> The situation is hard or imposible to reproduce if:
> - You disable completely persistence.
> - You add some synchronized code in the client, between the lines:
> msg =3D consumer.receive(2000),
> session.commit();
> like the commented statement incrConsumedCount(), perhaps shortening the =
probability of a race condition.
> - You run only a client at once (perhaps the problem only happens with co=
nsumers from different connections simultaneously)
> - If you don't use multicast to connect to the broker. I'm using, as jndi=
.properties:
> java.naming.provider.url =3D discovery:(multicast://planb.llu.xxxx)
> and the same discoveryUri in a openwire connector in the broker. I'm atta=
ching the client I've used and the configuration to reproduce the problem.
> - I was not able to reproduce it using 4.1.1

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.