[
https://issues.apache.org/jira/browse/ARTEMIS-4095?focusedWorklogId=868781&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-868781
]
ASF GitHub Bot logged work on ARTEMIS-4095:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Jun/23 19:30
Start Date: 30/Jun/23 19:30
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4529:
URL:
https://github.com/apache/activemq-artemis/pull/4529#issuecomment-1615110201
> If I understand the flow correctly, the server creates an internal
session, opens a transaction and uses it to transfer the data to a subscriber.
As noted previously, the `internalSession` you pointed out in
`o.a.a.a.c.p.o.OpenWireConnection` is an `o.a.a.a.c.s.ServerSession`. This is a
_core_ session, and it can't be used to transfer data to an OpenWire client.
Furthermore, it doesn't have anything to do with the
`o.a.a.a.c.p.o.a.AMQSession` for which `isInternal()` is returning `true` and
triggering this problem.
I looked through the source code of the OpenWire JMS and I see a handful of
places where the session ID is set to `-1` which would cause
`o.a.a.a.c.p.o.a.AMQSession#isInternal()` to return `true`. I still don't
understand _why_ this is done, but it helps to understand where it's coming
from.
Please take care of the checkstyle issues with your PR and then I'll merge
it. Thanks!
Issue Time Tracking
-------------------
Worklog Id: (was: 868781)
Time Spent: 1h 10m (was: 1h)
> 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
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 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)
