[
https://issues.apache.org/activemq/browse/AMQ-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicusor Tanase updated AMQ-1918:
--------------------------------
Attachment: testdata.zip
Hi,
You can use the test cases from the attached archive to reproduce the problem.
jmeterjms_nic-1.0.jar - modified version of the existing JMS sampler from
JMeter project
JMS Request Only.jmx - test plan for sender
JMS Receive Only.jmx - test plan for receiver.
You need to use version 2.3.3 of Jmeter and replace ApacheJMeter_jms.jar with
the modified one.
Sampler code is not closing the connections, so you need to restart Jmeter
clients between tests.
I hope the JMS sampler will make testing easier.
I consistently get the following problem, using the attached test cases (actual
figures may vary).
The broker is configured to use Oracle10 for persistence. I have created a
trigger that copies the records deleted from ACTIVEMQ_MSGS into
ACTIVEMQ_HISTORY table so I can see what has been produced and consumed at the
persistence layer.
1. Start Jmeter with 3 producer threads each sending 3333 messages
2. Start Jmeter with a consumer thread.
3. Let the producers finish (9999 messages sent to the broker)
4. Wait for consumer to fetch all 9999 messages.
5. Consumer stops receiving after 9860 messages (as reported by Jmeter Summary
Report).
6. Table ACTIVEMQ_MSGS contains 304 messages.
7. Table ACTIVEMQ_HISTORY contains 9695 messages.
8. JMX statistics show that the queue contains 139 messages.
9. Trying to browse the queue via JConsole does not return any messages.
Nic
> AbstractStoreCursor.size gets out of synch with Store size and blocks
> consumers
> -------------------------------------------------------------------------------
>
> Key: AMQ-1918
> URL: https://issues.apache.org/activemq/browse/AMQ-1918
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.1.0
> Reporter: Richard Yarger
> Assignee: Rob Davies
> Priority: Critical
> Fix For: 5.3.0
>
> Attachments: activemq.xml, testAMQMessageStore.zip, testdata.zip
>
>
> In version 5.1.0, we are seeing our queue consumers stop consuming for no
> reason.
> We have a staged queue environment and we occasionally see one queue display
> negative pending message counts that hang around -x, rise to -x+n gradually
> and then fall back to -x abruptly. The messages are building up and being
> processed in bunches but its not easy to see because the counts are negative.
> We see this behavior in the messages coming out of the system. Outbound
> messages come out in bunches and are synchronized with the queue pending
> count dropping to -x.
> This issue does not happen ALL of the time. It happens about once a week and
> the only way to fix it is to bounce the broker. It doesn't happen to the same
> queue everytime, so it is not our consuming code.
> Although we don't have a reproducible scenario, we have been able to debug
> the issue in our test environment.
> We traced the problem to the cached store size in the AbstractStoreCursor.
> This value becomes 0 or negative and prevents the AbstractStoreCursor from
> retrieving more messages from the store. (see AbstractStoreCursor.fillBatch()
> )
> We have seen size value go lower than -1000.
> We have also forced it to fix itself by sending in n+1 messages. Once the
> size goes above zero, the cached value is refreshed and things work ok again.
> Unfortunately, during low volume times, it could be hours before n+1 messages
> are received, so our message latency can rise during low volume times.... :(
> I have attached our broker config.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
