[
https://issues.apache.org/jira/browse/ARTEMIS-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736635#comment-17736635
]
Artyom Tarasenko commented on ARTEMIS-4095:
-------------------------------------------
Now, knowing that the problem is in the accounting of the persistentSize of the
delivering messages, it was easy to find the reason why it keeps growing:
incrementDeliverered() size in the test scenario above is always adding more
than decrementDeliverered(). It's possible to see it when sending a single
message and consume it with a XA Consumer: the persistentCount drops to 0, but
persistenSize stays >0. Comparing the refereneces for incrementing and
decrementing it turned out that the incrementing message has "__AMQ_CID"
property set, while decrement doesn't have it. Which in turn happens because
the fix for ARTEMIS-980 has a (meanwhile?) wrong assumption about the internal
sessions:
{code:java}
//internal session always delivers messages to noLocal advisory
consumers
//so we need to remove this property too.
message.removeProperty(MessageUtil.CONNECTION_ID_PROPERTY_NAME);{code}
The assumption is wrong because internal sessions are also used for handling
the XA-Transactions. The attached patch fixes the issue for me. [~jbertram]
would it be possible to include it into the next release? And since it's a
bugfix into a minor release too?
[^0001-ARTEMIS-4095-fix-delivering-message-size-accounting.patch]
> OpenWire clients are unable to consume from mutlicast queue after 2nd paging
> ----------------------------------------------------------------------------
>
> Key: ARTEMIS-4095
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4095
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
> Affects Versions: 2.26.0, 2.27.0, 2.27.1, 2.28.0, 2.29.0
> Environment: Artemis, deployed through the official docker image in
> version {{2.26.0}} in an OpenShift cluster
> Reporter: Marco Bungart
> Priority: Major
> Attachments:
> 0001-ARTEMIS-4095-fix-delivering-message-size-accounting.patch,
> artemis-Xmx1G.png, artemis-Xmx2G.png, graph1.png, graph2.png,
> jmeter-orders-6500-localhost.jmx, jmsconsumer-1.0-SNAPSHOT.jar
>
>
> I observed that after artemis went into paging for the 2nd time, OpenWire
> clients were not able to read messages from their corresponding addresses.
> Restarting the applications connected as clients does not fix the issue.
> Restarting artemis, however, does fix the issue.
> Both images attached show the messages of two queues.
> - The upper (orange) line in the 1st graph shows count of messages in a queue
> to which core clients are connected.
> - The lower (blue) line in the 1stg raph shows count of messages in a queue
> to which OpenWire clients are connected.
> - in the 2nd graph, the upper (violet) line shows count of messages in a
> queue to which core clients are connected.
> - in the 2nd graph, the lower (green) line shows count of messages in a queue
> to which OpenWire clients are connected.
> I have a heap dump that we could share, showing the accumulated objects. the
> dump is about 90 MB in size If this would be helpful to have, please let me
> know.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
