[
https://issues.apache.org/activemq/browse/AMQ-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sitsky updated AMQ-1251:
------------------------------
Attachment: TestActiveMQSyncReceive.java
Similar unit test to TestActiveMQ, except it has been rewritten to use
synchronous receives, which is how my main application works now.
I still get the unit test hanging about 50% of the time when the number of
worker threads is 2 or more, and interestingly when the prefetch size is 0. If
the prefetch is set to 1 or more, then the program _seems_ to work.
Whatever the problem is, both with this test and the previous one, there is
some sort of race condition, since the program doesn't always hang.
Whenever the program hangs, it seems the PendingQueueSize values for the queue
subscriptions are very large, in fact when I add the values up from all worker
queue subscriptions, it seems to equal the total number of messages which have
been sent to the queue.
When the program works, as expected, the PendingQueueSize on the subscriptions
is 0.
Any ideas what is wrong? This is with checkout 572492 and built using mvn
-Dmaven.test.skip=true clean install.
> Broker stops delivering messages to some consumers
> --------------------------------------------------
>
> Key: AMQ-1251
> URL: https://issues.apache.org/activemq/browse/AMQ-1251
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 4.1.0
> Environment: WinXP
> Reporter: Vadim Pesochinskiy
> Assignee: Rob Davies
> Fix For: 5.0.0
>
> Attachments: TestActiveMQ.java, TestActiveMQSyncReceive.java
>
>
> I have around 40 consumers taking messages from a single queue. After awhile
> 1 or 2 consumers stop receiveing any messages. Going to JMX and stopping
> corresponding connection causes re-connect and messages are delivered again.
> I reproduced it twice in QA enviroment and now it happened in production. I
> tried to instrument the code and set the log in debug, but that changed
> timing and I failed to reproduce it after the changes.
> I suspect that runtime association b/w Queue and Consumer objects is lost on
> the Broker side.
> One of the suspects is the empty catch block in the RoundRobinDispatchPolicy
> (line 64) class. It is possible that the CopyOnWrite array list is messed up
> and it fails when removed consumer is added back.
> BTW CopyOnWrite list is good when you mostly read, but not so good when you
> write for every message delivery and empty catch blocks are bad in any case.
> if (firstMatchingConsumer != null) {
> // Rotate the consumer list.
> try {
> consumers.remove(firstMatchingConsumer);
> consumers.add(firstMatchingConsumer);
> } catch (Throwable bestEffort) {
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
