[
https://issues.apache.org/activemq/browse/AMQ-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40301
]
David Sitsky commented on AMQ-1251:
-----------------------------------
Hi Rob,
Thanks - I can confirm that I no longer see the following messages:
"java.lang.RuntimeException: not implemented
at
org.apache.activemq.broker.region.NullMessageReference.isDropped(NullMessageReference.java:47)"
Now I would mark this issue as resolved from my perspective, except I hadn't
heard back from Hiram about one of my previous comments above:
> Hi Hiram,
>
> Many thanks for fixing this issue - all my unit tests now work, and my
> application runs far further than it used to - I suspect these problems are
> mine now .
>
> I am curious though, your change to VMPendingMessageCursor makes sense in
> that isEmpty() need to ignore dropped messages. Do we not need to make a
> similar
> change for other implementations of PendingMessageCursor, such as
> FilePendingMessageCursor and StoreQueueCursor?
>
> Cheers,
> David
> 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: QueueWorkerPrefetchTest.java, 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.
