[jira] [Resolved] (AMQ-9107) Closing many consumers causes CPU to spike to 100%
[ https://issues.apache.org/jira/browse/AMQ-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9107. --- Resolution: Fixed > Closing many consumers causes CPU to spike to 100% > -- > > Key: AMQ-9107 > URL: https://issues.apache.org/jira/browse/AMQ-9107 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.17.1, 5.16.5 >Reporter: Lucas Tétreault >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.18.0, 5.16.6, 5.17.3 > > Attachments: example.zip, image-2022-10-07-00-12-39-657.png, > image-2022-10-07-00-17-30-657.png > > Time Spent: 20m > Remaining Estimate: 0h > > When there are many consumers (~188k) on a queue, closing them is incredibly > expensive and causes the CPU to spike to 100% while the consumers are closed. > Tested on an Amazon MQ mq.m5.large instance (2 vcpu, 8gb memory). > I have attached a minimal recreation of the issue where the following > happens: > 1/ Open 100 connections. > 2/ Create consumers as fast as we can on all of those connections until we > hit at least 188k consumers. > 3/ Sleep for 5 minutes so we can observe the CPU come back down after opening > all those connections. > 4/ Start closing consumers as fast as we can. > 5/ After all consumers are closed, sleep for 5 minutes to observe the CPU > come back down after closing all the connections. > > In this example it seems 5 minutes wasn't actually sufficient time for the > CPU to come back down and the consumer and connection counts seem to hit 0 at > the same time: > !image-2022-10-07-00-12-39-657.png|width=757,height=353! > > In a previous test with more time sleeping after closing all the consumers we > can see the CPU come back down before we close the connections. > !image-2022-10-07-00-17-30-657.png|width=764,height=348! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9107) Closing many consumers causes CPU to spike to 100%
[ https://issues.apache.org/jira/browse/AMQ-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616765#comment-17616765 ] ASF subversion and git services commented on AMQ-9107: -- Commit 96a011d4b1527590b07d6e74f4c6f9a06dbab409 in activemq's branch refs/heads/main from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=96a011d4b ] Merge pull request #908 from lucastetreault/AMQ-9107 [AMQ-9107] Remove consumers more efficiently in ManagedRegionBroker > Closing many consumers causes CPU to spike to 100% > -- > > Key: AMQ-9107 > URL: https://issues.apache.org/jira/browse/AMQ-9107 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.17.1, 5.16.5 >Reporter: Lucas Tétreault >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.18.0, 5.16.6, 5.17.3 > > Attachments: example.zip, image-2022-10-07-00-12-39-657.png, > image-2022-10-07-00-17-30-657.png > > Time Spent: 20m > Remaining Estimate: 0h > > When there are many consumers (~188k) on a queue, closing them is incredibly > expensive and causes the CPU to spike to 100% while the consumers are closed. > Tested on an Amazon MQ mq.m5.large instance (2 vcpu, 8gb memory). > I have attached a minimal recreation of the issue where the following > happens: > 1/ Open 100 connections. > 2/ Create consumers as fast as we can on all of those connections until we > hit at least 188k consumers. > 3/ Sleep for 5 minutes so we can observe the CPU come back down after opening > all those connections. > 4/ Start closing consumers as fast as we can. > 5/ After all consumers are closed, sleep for 5 minutes to observe the CPU > come back down after closing all the connections. > > In this example it seems 5 minutes wasn't actually sufficient time for the > CPU to come back down and the consumer and connection counts seem to hit 0 at > the same time: > !image-2022-10-07-00-12-39-657.png|width=757,height=353! > > In a previous test with more time sleeping after closing all the consumers we > can see the CPU come back down before we close the connections. > !image-2022-10-07-00-17-30-657.png|width=764,height=348! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9107) Closing many consumers causes CPU to spike to 100%
[ https://issues.apache.org/jira/browse/AMQ-9107?focusedWorklogId=816422=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816422 ] ASF GitHub Bot logged work on AMQ-9107: --- Author: ASF GitHub Bot Created on: 13/Oct/22 03:58 Start Date: 13/Oct/22 03:58 Worklog Time Spent: 10m Work Description: jbonofre merged PR #908: URL: https://github.com/apache/activemq/pull/908 Issue Time Tracking --- Worklog Id: (was: 816422) Time Spent: 20m (was: 10m) > Closing many consumers causes CPU to spike to 100% > -- > > Key: AMQ-9107 > URL: https://issues.apache.org/jira/browse/AMQ-9107 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.17.1, 5.16.5 >Reporter: Lucas Tétreault >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.18.0, 5.16.6, 5.17.3 > > Attachments: example.zip, image-2022-10-07-00-12-39-657.png, > image-2022-10-07-00-17-30-657.png > > Time Spent: 20m > Remaining Estimate: 0h > > When there are many consumers (~188k) on a queue, closing them is incredibly > expensive and causes the CPU to spike to 100% while the consumers are closed. > Tested on an Amazon MQ mq.m5.large instance (2 vcpu, 8gb memory). > I have attached a minimal recreation of the issue where the following > happens: > 1/ Open 100 connections. > 2/ Create consumers as fast as we can on all of those connections until we > hit at least 188k consumers. > 3/ Sleep for 5 minutes so we can observe the CPU come back down after opening > all those connections. > 4/ Start closing consumers as fast as we can. > 5/ After all consumers are closed, sleep for 5 minutes to observe the CPU > come back down after closing all the connections. > > In this example it seems 5 minutes wasn't actually sufficient time for the > CPU to come back down and the consumer and connection counts seem to hit 0 at > the same time: > !image-2022-10-07-00-12-39-657.png|width=757,height=353! > > In a previous test with more time sleeping after closing all the consumers we > can see the CPU come back down before we close the connections. > !image-2022-10-07-00-17-30-657.png|width=764,height=348! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9107) Closing many consumers causes CPU to spike to 100%
[ https://issues.apache.org/jira/browse/AMQ-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-9107: -- Fix Version/s: 5.18.0 5.16.6 5.17.3 > Closing many consumers causes CPU to spike to 100% > -- > > Key: AMQ-9107 > URL: https://issues.apache.org/jira/browse/AMQ-9107 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.17.1, 5.16.5 >Reporter: Lucas Tétreault >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.18.0, 5.16.6, 5.17.3 > > Attachments: example.zip, image-2022-10-07-00-12-39-657.png, > image-2022-10-07-00-17-30-657.png > > Time Spent: 10m > Remaining Estimate: 0h > > When there are many consumers (~188k) on a queue, closing them is incredibly > expensive and causes the CPU to spike to 100% while the consumers are closed. > Tested on an Amazon MQ mq.m5.large instance (2 vcpu, 8gb memory). > I have attached a minimal recreation of the issue where the following > happens: > 1/ Open 100 connections. > 2/ Create consumers as fast as we can on all of those connections until we > hit at least 188k consumers. > 3/ Sleep for 5 minutes so we can observe the CPU come back down after opening > all those connections. > 4/ Start closing consumers as fast as we can. > 5/ After all consumers are closed, sleep for 5 minutes to observe the CPU > come back down after closing all the connections. > > In this example it seems 5 minutes wasn't actually sufficient time for the > CPU to come back down and the consumer and connection counts seem to hit 0 at > the same time: > !image-2022-10-07-00-12-39-657.png|width=757,height=353! > > In a previous test with more time sleeping after closing all the consumers we > can see the CPU come back down before we close the connections. > !image-2022-10-07-00-17-30-657.png|width=764,height=348! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9120) Upgrade to shiro 1.10.0
Jean-Baptiste Onofré created AMQ-9120: - Summary: Upgrade to shiro 1.10.0 Key: AMQ-9120 URL: https://issues.apache.org/jira/browse/AMQ-9120 Project: ActiveMQ Issue Type: Dependency upgrade Components: Security/JAAS Reporter: Jean-Baptiste Onofré Assignee: Jean-Baptiste Onofré Fix For: 5.18.0, 5.16.6, 5.17.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
[
https://issues.apache.org/jira/browse/AMQ-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved AMQ-9119.
---
Resolution: Fixed
> ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers
> when a consumer disconnects.
> --
>
> Key: AMQ-9119
> URL: https://issues.apache.org/jira/browse/AMQ-9119
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.15.11, 5.16.0
>Reporter: Lucas Tétreault
>Assignee: Jean-Baptiste Onofré
>Priority: Trivial
> Fix For: 5.18.0, 5.16.6, 5.17.3
>
> Attachments: image-2022-10-12-18-37-41-001.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the consumer subscribed to the advisory topic uses AMQP it only receives
> "ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
> message. If the consumer subscribed to the advisory topic uses Openwire both
> the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
> appears to be a regression related to AMQ-7068.
>
> In the logs we see an error like the following:
> {{WARN AmqpSender- Error detected while flushing outbound
> messages: No encoding is known for map entry value of type:
> org.apache.activemq.command.SessionId}}
>
> We also noticed that the console shows the messages are Inflight but they are
> never received by the consumer:
> !image-2022-10-12-18-37-41-001.png|width=1627,height=478!
>
> I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
[
https://issues.apache.org/jira/browse/AMQ-9119?focusedWorklogId=816421=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816421
]
ASF GitHub Bot logged work on AMQ-9119:
---
Author: ASF GitHub Bot
Created on: 13/Oct/22 03:54
Start Date: 13/Oct/22 03:54
Worklog Time Spent: 10m
Work Description: jbonofre merged PR #919:
URL: https://github.com/apache/activemq/pull/919
Issue Time Tracking
---
Worklog Id: (was: 816421)
Remaining Estimate: 0h
Time Spent: 10m
> ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers
> when a consumer disconnects.
> --
>
> Key: AMQ-9119
> URL: https://issues.apache.org/jira/browse/AMQ-9119
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.15.11, 5.16.0
>Reporter: Lucas Tétreault
>Assignee: Jean-Baptiste Onofré
>Priority: Trivial
> Fix For: 5.18.0, 5.16.6, 5.17.3
>
> Attachments: image-2022-10-12-18-37-41-001.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the consumer subscribed to the advisory topic uses AMQP it only receives
> "ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
> message. If the consumer subscribed to the advisory topic uses Openwire both
> the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
> appears to be a regression related to AMQ-7068.
>
> In the logs we see an error like the following:
> {{WARN AmqpSender- Error detected while flushing outbound
> messages: No encoding is known for map entry value of type:
> org.apache.activemq.command.SessionId}}
>
> We also noticed that the console shows the messages are Inflight but they are
> never received by the consumer:
> !image-2022-10-12-18-37-41-001.png|width=1627,height=478!
>
> I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
[
https://issues.apache.org/jira/browse/AMQ-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616764#comment-17616764
]
ASF subversion and git services commented on AMQ-9119:
--
Commit 3bcbc5b847da43f97125490925335d7ce45b53e8 in activemq's branch
refs/heads/main from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=3bcbc5b84 ]
Merge pull request #919 from lucastetreault/AMQ-9119
[AMQ-9119] Fix serialization of RemoveInfo advisory message for AMQP consumers
> ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers
> when a consumer disconnects.
> --
>
> Key: AMQ-9119
> URL: https://issues.apache.org/jira/browse/AMQ-9119
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.15.11, 5.16.0
>Reporter: Lucas Tétreault
>Assignee: Jean-Baptiste Onofré
>Priority: Trivial
> Fix For: 5.18.0, 5.16.6, 5.17.3
>
> Attachments: image-2022-10-12-18-37-41-001.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the consumer subscribed to the advisory topic uses AMQP it only receives
> "ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
> message. If the consumer subscribed to the advisory topic uses Openwire both
> the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
> appears to be a regression related to AMQ-7068.
>
> In the logs we see an error like the following:
> {{WARN AmqpSender- Error detected while flushing outbound
> messages: No encoding is known for map entry value of type:
> org.apache.activemq.command.SessionId}}
>
> We also noticed that the console shows the messages are Inflight but they are
> never received by the consumer:
> !image-2022-10-12-18-37-41-001.png|width=1627,height=478!
>
> I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
[
https://issues.apache.org/jira/browse/AMQ-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned AMQ-9119:
-
Assignee: Jean-Baptiste Onofré
> ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers
> when a consumer disconnects.
> --
>
> Key: AMQ-9119
> URL: https://issues.apache.org/jira/browse/AMQ-9119
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.15.11, 5.16.0
>Reporter: Lucas Tétreault
>Assignee: Jean-Baptiste Onofré
>Priority: Trivial
> Attachments: image-2022-10-12-18-37-41-001.png
>
>
> When the consumer subscribed to the advisory topic uses AMQP it only receives
> "ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
> message. If the consumer subscribed to the advisory topic uses Openwire both
> the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
> appears to be a regression related to AMQ-7068.
>
> In the logs we see an error like the following:
> {{WARN AmqpSender- Error detected while flushing outbound
> messages: No encoding is known for map entry value of type:
> org.apache.activemq.command.SessionId}}
>
> We also noticed that the console shows the messages are Inflight but they are
> never received by the consumer:
> !image-2022-10-12-18-37-41-001.png|width=1627,height=478!
>
> I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
[
https://issues.apache.org/jira/browse/AMQ-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-9119:
--
Fix Version/s: 5.18.0
5.16.6
5.17.3
> ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers
> when a consumer disconnects.
> --
>
> Key: AMQ-9119
> URL: https://issues.apache.org/jira/browse/AMQ-9119
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.15.11, 5.16.0
>Reporter: Lucas Tétreault
>Assignee: Jean-Baptiste Onofré
>Priority: Trivial
> Fix For: 5.18.0, 5.16.6, 5.17.3
>
> Attachments: image-2022-10-12-18-37-41-001.png
>
>
> When the consumer subscribed to the advisory topic uses AMQP it only receives
> "ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
> message. If the consumer subscribed to the advisory topic uses Openwire both
> the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
> appears to be a regression related to AMQ-7068.
>
> In the logs we see an error like the following:
> {{WARN AmqpSender- Error detected while flushing outbound
> messages: No encoding is known for map entry value of type:
> org.apache.activemq.command.SessionId}}
>
> We also noticed that the console shows the messages are Inflight but they are
> never received by the consumer:
> !image-2022-10-12-18-37-41-001.png|width=1627,height=478!
>
> I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4036) mqtt client receive 131 code
[
https://issues.apache.org/jira/browse/ARTEMIS-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616762#comment-17616762
]
Justin Bertram commented on ARTEMIS-4036:
-
A return code {{131}} (i.e. {{0x83}}) can be sent to a client if a packet is
handled while the client's internal session is in the process of stopping or
some other unforeseen error occurred while processing the packet. The latter
will be accompanied by a corresponding {{ERROR}} message in the log saying
something like "Error processing control packet" along with an exception and a
logging code of 834002. Do you see any log entries like this?
> mqtt client receive 131 code
>
>
> Key: ARTEMIS-4036
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4036
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: gongping.zhu
>Priority: Major
>
> sometimes mqtt client connect the server ; it will receive The Server
> Disconnected the client. Disconnect RC: 131
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4036) mqtt client receive 131 code
[ https://issues.apache.org/jira/browse/ARTEMIS-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4036: --- Assignee: (was: Clebert Suconic) > mqtt client receive 131 code > > > Key: ARTEMIS-4036 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4036 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.25.0 >Reporter: gongping.zhu >Priority: Major > > sometimes mqtt client connect the server ; it will receive The Server > Disconnected the client. Disconnect RC: 131 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4036) mqtt client receive 131 code
[ https://issues.apache.org/jira/browse/ARTEMIS-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4036: Component/s: (was: ActiveMQ-Artemis-Native) > mqtt client receive 131 code > > > Key: ARTEMIS-4036 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4036 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.25.0 >Reporter: gongping.zhu >Assignee: Clebert Suconic >Priority: Major > > sometimes mqtt client connect the server ; it will receive The Server > Disconnected the client. Disconnect RC: 131 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4046) mqtt $share topic can not work
[
https://issues.apache.org/jira/browse/ARTEMIS-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616759#comment-17616759
]
Justin Bertram commented on ARTEMIS-4046:
-
Can you be more specific (ideally with a reproducible test-case)? The tests in
the test-suite which exercise MQTT functionality with {{$share/}} are still
passing.
> mqtt $share topic can not work
> --
>
> Key: ARTEMIS-4046
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4046
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.26.0
>Reporter: gongping.zhu
>Priority: Major
>
> When I use version 2.25.0, I can correctly use the share topic mechanism;
> When I upgrade to 2.26.0, the share topic mechanism cannot work；
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4046) mqtt $share topic can not work
[ https://issues.apache.org/jira/browse/ARTEMIS-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4046: Component/s: (was: AMQP) > mqtt $share topic can not work > -- > > Key: ARTEMIS-4046 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4046 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.26.0 >Reporter: gongping.zhu >Priority: Major > > When I use version 2.25.0, I can correctly use the share topic mechanism; > When I upgrade to 2.26.0, the share topic mechanism cannot work； > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4046) mqtt $share topic can not work
gongping.zhu created ARTEMIS-4046: - Summary: mqtt $share topic can not work Key: ARTEMIS-4046 URL: https://issues.apache.org/jira/browse/ARTEMIS-4046 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.26.0 Reporter: gongping.zhu When I use version 2.25.0, I can correctly use the share topic mechanism; When I upgrade to 2.26.0, the share topic mechanism cannot work； -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9119) ActiveMQ not sending `RemoveInfo` advisory message to AMQP advisory consumers when a consumer disconnects.
Lucas Tétreault created AMQ-9119:
Summary: ActiveMQ not sending `RemoveInfo` advisory message to
AMQP advisory consumers when a consumer disconnects.
Key: AMQ-9119
URL: https://issues.apache.org/jira/browse/AMQ-9119
Project: ActiveMQ
Issue Type: Bug
Components: AMQP
Affects Versions: 5.16.0, 5.15.11
Reporter: Lucas Tétreault
Attachments: image-2022-10-12-18-37-41-001.png
When the consumer subscribed to the advisory topic uses AMQP it only receives
"ConsumerInfo" (consumer=1) and never receives the "RemoveInfo" (consumer=0)
message. If the consumer subscribed to the advisory topic uses Openwire both
the "ConsumerInfo" and "RemoveInfo" messages are received as expected. This
appears to be a regression related to AMQ-7068.
In the logs we see an error like the following:
{{WARN AmqpSender- Error detected while flushing outbound
messages: No encoding is known for map entry value of type:
org.apache.activemq.command.SessionId}}
We also noticed that the console shows the messages are Inflight but they are
never received by the consumer:
!image-2022-10-12-18-37-41-001.png|width=1627,height=478!
I have a fix and will prepare a PR right away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4045) AMQ224041: Failed to deliver in mirror
[
https://issues.apache.org/jira/browse/ARTEMIS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616739#comment-17616739
]
Stephen Baker commented on ARTEMIS-4045:
See the attachment for a trace log of the error.
> AMQ224041: Failed to deliver in mirror
> --
>
> Key: ARTEMIS-4045
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4045
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Stephen Baker
>Priority: Major
> Attachments: expire_error_mirror.log
>
>
> I saw the following stack trace when running artemis 2.25 to artemis 2.25 in
> a dual mirror configuration with docker instances.
> The side that has the error is the only side running the message expiry scan.
> Messages were added to the other side through JMS with a short (10s) expiry.
> {code:java}
> artemis-test-artemis-1-m-1 | 2022-10-12 22:02:13,468 ERROR
> [org.apache.activemq.artemis.core.server] AMQ224041: Failed to deliver:
> java.lang.IllegalStateException: this method requires to be called within the
> handler, use the executor
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.requireHandler(ProtonHandler.java:210)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.requireInHandler(AMQPConnectionContext.java:197)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonAbstractReceiver.settle(ProtonAbstractReceiver.java:185)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget$ACKMessageOperation.run(AMQPMirrorControllerTarget.java:125)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.performAck(AMQPMirrorControllerTarget.java:388)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.lambda$performAck$2(AMQPMirrorControllerTarget.java:377)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$2.skipDelivery(QueueImpl.java:1203)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2932)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2991)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4250)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> artemis-test-artemis-1-m-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 |{code}
> I believe the stack may be enough to diagnose the issue. It's very
> specifically calling run directly where all the other code paths run it
> through an executor, and the error says that it can't be run directly.
>
> From AMQPMirrorControllerTarget
> {code:java}
> switch (retry) {
>case 0:
> // first retry, after IO Operations
> sessionSPI.getSessionContext().executeOnCompletion(new
> RunnableCallback(() -> performAck(nodeID, messageID, targetQueue,
> ackMessageOperation, reason, (short) 1)));
> return;
>case 1:
> // second retry after the queue is flushed the temporary adds
> targetQueue.flushOnIntermediate(() -> {
> recoverContext();
> performAck(nodeID, messageID, targetQueue, ackMessageOperation,
> reason,
[jira] [Updated] (ARTEMIS-4045) AMQ224041: Failed to deliver in mirror
[
https://issues.apache.org/jira/browse/ARTEMIS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Baker updated ARTEMIS-4045:
---
Attachment: expire_error_mirror.log
> AMQ224041: Failed to deliver in mirror
> --
>
> Key: ARTEMIS-4045
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4045
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Stephen Baker
>Priority: Major
> Attachments: expire_error_mirror.log
>
>
> I saw the following stack trace when running artemis 2.25 to artemis 2.25 in
> a dual mirror configuration with docker instances.
> The side that has the error is the only side running the message expiry scan.
> Messages were added to the other side through JMS with a short (10s) expiry.
> {code:java}
> artemis-test-artemis-1-m-1 | 2022-10-12 22:02:13,468 ERROR
> [org.apache.activemq.artemis.core.server] AMQ224041: Failed to deliver:
> java.lang.IllegalStateException: this method requires to be called within the
> handler, use the executor
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.requireHandler(ProtonHandler.java:210)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.requireInHandler(AMQPConnectionContext.java:197)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonAbstractReceiver.settle(ProtonAbstractReceiver.java:185)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget$ACKMessageOperation.run(AMQPMirrorControllerTarget.java:125)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.performAck(AMQPMirrorControllerTarget.java:388)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.lambda$performAck$2(AMQPMirrorControllerTarget.java:377)
> [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$2.skipDelivery(QueueImpl.java:1203)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2932)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2991)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4250)
> [artemis-server-2.25.0.jar:2.25.0]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> artemis-test-artemis-1-m-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> artemis-test-artemis-1-m-1 | at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.25.0.jar:]
> artemis-test-artemis-1-m-1 |{code}
> I believe the stack may be enough to diagnose the issue. It's very
> specifically calling run directly where all the other code paths run it
> through an executor, and the error says that it can't be run directly.
>
> From AMQPMirrorControllerTarget
> {code:java}
> switch (retry) {
>case 0:
> // first retry, after IO Operations
> sessionSPI.getSessionContext().executeOnCompletion(new
> RunnableCallback(() -> performAck(nodeID, messageID, targetQueue,
> ackMessageOperation, reason, (short) 1)));
> return;
>case 1:
> // second retry after the queue is flushed the temporary adds
> targetQueue.flushOnIntermediate(() -> {
> recoverContext();
> performAck(nodeID, messageID, targetQueue, ackMessageOperation,
> reason, (short)2);
> });
> return;
>case 2:
>
[jira] [Commented] (ARTEMIS-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616733#comment-17616733
]
Stephen Baker commented on ARTEMIS-3728:
Opened ARTEMIS-4045 for that. If you don't think this issue provides value or
it's likely to have been resolved you can close it. It may be months before I
can provide a satisfactory update, and I can always reopen.
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2938)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2963)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4205)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.20.0.jar:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.20.0.jar:]{noformat}
> I don't know how it started or how to reproduce, but I can say that we
> switched to dual mirroring last night per the [current
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html].
> In the process we renamed our mirrors (before they had the same name on each
> side), and deleted the old mirror queues through the management console after
> all of the servers were up. We did this on 4 other pairs (all separate
> clusters) without running into this issue.
> These errors are coming only from the live server on the disaster recovery
> site, which has no consumers except the mirror connection.
> Prior to these errors we did have:
> {noformat}
> 2022-03-16 23:52:29,482 WARN
> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget]
> Queue $ACTIVEMQ_ARTEMIS_MIRROR_Mirror not found on mirror target, ignoring
> ack for queue=$ACTIVEMQ_ARTEMIS_MIRROR_Mirror, messageID=63165878649,
> nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2{noformat}
> in our logs, where that mirror name is the old shared mirror name (not part
> of the current broker.xml).
> Error does not appear to have come back on a restart of the server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4045) AMQ224041: Failed to deliver in mirror
Stephen Baker created ARTEMIS-4045:
--
Summary: AMQ224041: Failed to deliver in mirror
Key: ARTEMIS-4045
URL: https://issues.apache.org/jira/browse/ARTEMIS-4045
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Stephen Baker
I saw the following stack trace when running artemis 2.25 to artemis 2.25 in a
dual mirror configuration with docker instances.
The side that has the error is the only side running the message expiry scan.
Messages were added to the other side through JMS with a short (10s) expiry.
{code:java}
artemis-test-artemis-1-m-1 | 2022-10-12 22:02:13,468 ERROR
[org.apache.activemq.artemis.core.server] AMQ224041: Failed to deliver:
java.lang.IllegalStateException: this method requires to be called within the
handler, use the executor
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.requireHandler(ProtonHandler.java:210)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.requireInHandler(AMQPConnectionContext.java:197)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.ProtonAbstractReceiver.settle(ProtonAbstractReceiver.java:185)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget$ACKMessageOperation.run(AMQPMirrorControllerTarget.java:125)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.performAck(AMQPMirrorControllerTarget.java:388)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.lambda$performAck$2(AMQPMirrorControllerTarget.java:377)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl$2.skipDelivery(QueueImpl.java:1203)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2932)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2991)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4250)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[java.base:]
artemis-test-artemis-1-m-1 | at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[java.base:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 |{code}
I believe the stack may be enough to diagnose the issue. It's very specifically
calling run directly where all the other code paths run it through an executor,
and the error says that it can't be run directly.
>From AMQPMirrorControllerTarget
{code:java}
switch (retry) {
case 0:
// first retry, after IO Operations
sessionSPI.getSessionContext().executeOnCompletion(new
RunnableCallback(() -> performAck(nodeID, messageID, targetQueue,
ackMessageOperation, reason, (short) 1)));
return;
case 1:
// second retry after the queue is flushed the temporary adds
targetQueue.flushOnIntermediate(() -> {
recoverContext();
performAck(nodeID, messageID, targetQueue, ackMessageOperation,
reason, (short)2);
});
return;
case 2:
// third retry, on paging
if (reason != AckReason.EXPIRED) {
// if expired, we don't need to check on paging
// as the message will expire again when depaged (if on paging)
performAckOnPage(nodeID, messageID, targetQueue, ackMessageOperation);
return;
} else {
ackMessageOperation.run();
}
} {code}
I'm not sure which is the right executor though. Nor do I have
[jira] [Commented] (ARTEMIS-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616731#comment-17616731
]
Justin Bertram commented on ARTEMIS-3728:
-
This looks like a different issue. Please open a new Jira for this.
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2938)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2963)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4205)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.20.0.jar:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.20.0.jar:]{noformat}
> I don't know how it started or how to reproduce, but I can say that we
> switched to dual mirroring last night per the [current
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html].
> In the process we renamed our mirrors (before they had the same name on each
> side), and deleted the old mirror queues through the management console after
> all of the servers were up. We did this on 4 other pairs (all separate
> clusters) without running into this issue.
> These errors are coming only from the live server on the disaster recovery
> site, which has no consumers except the mirror connection.
> Prior to these errors we did have:
> {noformat}
> 2022-03-16 23:52:29,482 WARN
> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget]
> Queue $ACTIVEMQ_ARTEMIS_MIRROR_Mirror not found on mirror target, ignoring
> ack for queue=$ACTIVEMQ_ARTEMIS_MIRROR_Mirror, messageID=63165878649,
> nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2{noformat}
> in our logs, where that mirror name is the old shared mirror name (not part
> of the current broker.xml).
> Error does not appear to have come back on a restart of the server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616714#comment-17616714
]
Stephen Baker commented on ARTEMIS-3728:
This later stack trace has a pretty clear cause, I think it probably deserves
it's own issue.
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2938)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2963)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4205)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.20.0.jar:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.20.0.jar:]{noformat}
> I don't know how it started or how to reproduce, but I can say that we
> switched to dual mirroring last night per the [current
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html].
> In the process we renamed our mirrors (before they had the same name on each
> side), and deleted the old mirror queues through the management console after
> all of the servers were up. We did this on 4 other pairs (all separate
> clusters) without running into this issue.
> These errors are coming only from the live server on the disaster recovery
> site, which has no consumers except the mirror connection.
> Prior to these errors we did have:
> {noformat}
> 2022-03-16 23:52:29,482 WARN
> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget]
> Queue $ACTIVEMQ_ARTEMIS_MIRROR_Mirror not found on mirror target, ignoring
> ack for queue=$ACTIVEMQ_ARTEMIS_MIRROR_Mirror, messageID=63165878649,
> nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2{noformat}
> in our logs, where that mirror name is the old shared mirror name (not part
> of the current broker.xml).
> Error does not appear to have come back on a restart of the server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616705#comment-17616705
]
Stephen Baker commented on ARTEMIS-3728:
I produced a somewhat similar error in 2.25:
{code:java}
artemis-test-artemis-1-m-1 | 2022-10-12 22:02:13,468 ERROR
[org.apache.activemq.artemis.core.server] AMQ224041: Failed to deliver:
java.lang.IllegalStateException: this method requires to be called within the
handler, use the executor
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.requireHandler(ProtonHandler.java:210)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.requireInHandler(AMQPConnectionContext.java:197)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.proton.ProtonAbstractReceiver.settle(ProtonAbstractReceiver.java:185)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget$ACKMessageOperation.run(AMQPMirrorControllerTarget.java:125)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.performAck(AMQPMirrorControllerTarget.java:388)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.lambda$performAck$2(AMQPMirrorControllerTarget.java:377)
[artemis-amqp-protocol-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl$2.skipDelivery(QueueImpl.java:1203)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2932)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2991)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4250)
[artemis-server-2.25.0.jar:2.25.0]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 | at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[java.base:]
artemis-test-artemis-1-m-1 | at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[java.base:]
artemis-test-artemis-1-m-1 | at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.25.0.jar:]
artemis-test-artemis-1-m-1 |{code}
Again this was on the live instance of the mirror, not the instance I was
producing/consuming from. Except that both are in deliver on the mirror queue
though I'm not sure they're related. Will open a separate issue if you think it
warrants it.
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
>
[jira] [Commented] (ARTEMIS-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616704#comment-17616704
]
Justin Bertram commented on ARTEMIS-3728:
-
Any luck reproducing? If not, do you mind if I close this as "Cannot Reproduce"?
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2938)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2963)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4205)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.20.0.jar:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.20.0.jar:]{noformat}
> I don't know how it started or how to reproduce, but I can say that we
> switched to dual mirroring last night per the [current
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html].
> In the process we renamed our mirrors (before they had the same name on each
> side), and deleted the old mirror queues through the management console after
> all of the servers were up. We did this on 4 other pairs (all separate
> clusters) without running into this issue.
> These errors are coming only from the live server on the disaster recovery
> site, which has no consumers except the mirror connection.
> Prior to these errors we did have:
> {noformat}
> 2022-03-16 23:52:29,482 WARN
> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget]
> Queue $ACTIVEMQ_ARTEMIS_MIRROR_Mirror not found on mirror target, ignoring
> ack for queue=$ACTIVEMQ_ARTEMIS_MIRROR_Mirror, messageID=63165878649,
> nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2{noformat}
> in our logs, where that mirror name is the old shared mirror name (not part
> of the current broker.xml).
> Error does not appear to have come back on a restart of the server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4041) Improve criticalIO reporting
[ https://issues.apache.org/jira/browse/ARTEMIS-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616694#comment-17616694 ] ASF subversion and git services commented on ARTEMIS-4041: -- Commit 7b2f7e1707ca86fee7b20513f3cf26e93c49927a in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7b2f7e1707 ] ARTEMIS-4041 Fixing NPE on SequentialFileFactory after the CriticalIO change > Improve criticalIO reporting > > > Key: ARTEMIS-4041 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4041 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some exceptions are not giving much context. > At the main cause, if for any reason such as a NFS not allocating the file > properly we would throw an IllegalStateException. > We should call FileFactory.onIOError directly in certain places, giving > emphasis to what file had issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616649#comment-17616649
]
Justin Bertram commented on ARTEMIS-4044:
-
Your conclusions correspond to my suspicions. Thanks for following up.
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Baker closed ARTEMIS-4044.
--
Resolution: Invalid
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616645#comment-17616645
]
Stephen Baker commented on ARTEMIS-4044:
Mind if I close this. I think it's just a timing issue with the server shutdown
disconnect exception. In all versions tested the behaviour appears to be the
same, and creating a fresh connection resolves it. The exception is sent async
so there's no guarantee it will be processed before the start. Differences seen
between versions are likely as anything to be timing coincidences (faster
shutdown/startup, more contention on the thread factory, any number of
possibilities)
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616633#comment-17616633
]
Justin Bertram edited comment on ARTEMIS-4044 at 10/12/22 6:28 PM:
---
Yeah, I'm fighting spring boot a little at the moment to get a raw connection
so I can create exactly the same scenario. My test in my last comment wasn't
great either, because that's a proxied SingleConnectionFactory connection, with
sometimes detects the close and creates a new connection even in that little
test, before we try to create the session.
{noformat}
javax.jms.JMSException: ActiveMQDisconnectedException[errorType=DISCONNECTED
message=AMQ219015: The connection was disconnected because of server shutdown]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:714)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:735)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.callSessionFailureListeners(ClientSessionFactoryImpl.java:767)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:702)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:537)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1299)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:78)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:222)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1073)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
~[artemis-commons-2.21.0.jar:na]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
~[artemis-commons-2.21.0.jar:na]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
~[artemis-commons-2.21.0.jar:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
~[artemis-commons-2.21.0.jar:na]
Caused by: org.apache.activemq.artemis.api.core.ActiveMQDisconnectedException:
AMQ219015: The connection was disconnected because of server shutdown
... 7 common frames omitted{noformat}
was (Author: sebaker):
Yeah, I'm fighting spring boot a little at the moment to get a raw connection
so I can create exactly the same scenario. My test in my last comment wasn't
great either, because that's a proxied SingleConnectionFactory connection, with
sometimes detects the close and creates a new connection even in that little
test, before we try to create the session.
{code:java}
javax.jms.JMSException: ActiveMQDisconnectedException[errorType=DISCONNECTED
message=AMQ219015: The connection was disconnected because of server shutdown]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:714)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:735)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.callSessionFailureListeners(ClientSessionFactoryImpl.java:767)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:702)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:537)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1299)
[jira] [Comment Edited] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616634#comment-17616634
]
Stephen Baker edited comment on ARTEMIS-4044 at 10/12/22 6:17 PM:
--
I wonder if that exception thrown at shutdown stopped happening...
Edit:
No it's still there.
was (Author: sebaker):
I wonder if that exception thrown at shutdown stopped happening...
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616634#comment-17616634
]
Stephen Baker commented on ARTEMIS-4044:
I wonder if that exception thrown at shutdown stopped happening...
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616633#comment-17616633
]
Stephen Baker commented on ARTEMIS-4044:
Yeah, I'm fighting spring boot a little at the moment to get a raw connection
so I can create exactly the same scenario. My test in my last comment wasn't
great either, because that's a proxied SingleConnectionFactory connection, with
sometimes detects the close and creates a new connection even in that little
test, before we try to create the session.
{code:java}
javax.jms.JMSException: ActiveMQDisconnectedException[errorType=DISCONNECTED
message=AMQ219015: The connection was disconnected because of server shutdown]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:714)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.jms.client.ActiveMQConnection$JMSFailureListener.connectionFailed(ActiveMQConnection.java:735)
~[artemis-jms-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.callSessionFailureListeners(ClientSessionFactoryImpl.java:767)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:702)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:537)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1299)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:78)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:222)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1073)
~[artemis-core-client-2.21.0.jar:2.21.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
~[artemis-commons-2.21.0.jar:na]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
~[artemis-commons-2.21.0.jar:na]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
~[artemis-commons-2.21.0.jar:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[na:na]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[na:na]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
~[artemis-commons-2.21.0.jar:na]
Caused by: org.apache.activemq.artemis.api.core.ActiveMQDisconnectedException:
AMQ219015: The connection was disconnected because of server shutdown
... 7 common frames omitted
{code}
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5,
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616632#comment-17616632
]
Justin Bertram commented on ARTEMIS-4044:
-
Looks like we were composing our comments at the same time...
It appears you've confirmed what I suggested in my previous comment. You are
able to see the failure before 2.24.0.
At this point it seems that this may be down to the way the client's URL is
configured in combination with how Spring's {{JmsTemplate}} handles exceptions.
Can you elaborate on how the client is connecting?
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616630#comment-17616630
]
Justin Bertram commented on ARTEMIS-4044:
-
bq. ...it is periodically failing to obtain a connection AFTER the server has
finished starting.
Based on [^failure.log] this is not quite accurate. The problem is actually
that Spring's {{JmsTemplate}} is unable to create a JMS session on a connection
that has already been closed. It's not actually trying to obtain a connection
per se. This is a subtle but important difference because it indicates a
different failure mode than the one seen in either [^success.log] or
[^success_2_19_1.log]. In [^success.log] there's no failure at all, and in
[^success_2_19_1.log] the failure happens when Spring's
{{JmsTransactionManager}} attempts to create a connection. However, in
[^failure.log] we see that the failure happens when {{JmsTemplate}} tries to
invoke {{javax.jms.Session.createQueue()}}.
It may be that you'd see the same inability to create a session once the broker
was restarted even in previous versions if you saw this same failure mode.
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616628#comment-17616628
]
Stephen Baker edited comment on ARTEMIS-4044 at 10/12/22 6:02 PM:
--
Working on it, I have a much simpler reproduction now that takes all the chance
out of it. 2.23.1 does have the new behaviour but I got unlucky with the
earlier test.
{code:java}
@Test
void proveMyPoint() throws Exception {
var connection = jmsTemplate.getConnectionFactory().createConnection();
embeddedActiveMQ.stop();
embeddedActiveMQ.start();
connection.createSession();
} {code}
was (Author: sebaker):
Working on it, I have a much simpler reproduction now that takes all the chance
out of it. 2.23.1 does have the new behaviour but I got unlucky with the
earlier test.
```
{color:#bbb529}@Test
{color}{color:#cc7832}void {color}{color:#ffc66d}proveMyPoint{color}()
{color:#cc7832}throws {color}Exception {
{color:#cc7832}var {color}connection =
{color:#9876aa}jmsTemplate{color}.getConnectionFactory().createConnection(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.stop(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.start(){color:#cc7832};
{color}{color:#cc7832} {color}connection.createSession(){color:#cc7832};
{color}}
```
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616628#comment-17616628
]
Stephen Baker commented on ARTEMIS-4044:
Working on it, I have a much simpler reproduction now that takes all the chance
out of it. 2.23.1 does have the new behaviour but I got unlucky with the
earlier test.
```
{color:#bbb529}@Test
{color}{color:#cc7832}void {color}{color:#ffc66d}proveMyPoint{color}()
{color:#cc7832}throws {color}Exception {
{color:#cc7832}var {color}connection =
{color:#9876aa}jmsTemplate{color}.getConnectionFactory().createConnection(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.stop(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.start(){color:#cc7832};
{color}{color:#cc7832} {color}connection.createSession(){color:#cc7832};
{color}}
```
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> }{code}
> * [^failure.log]
> * [^success.log]
> * [^success_2_19_1.log]
> When {{registerListener}} is called we expect a connection failure and on
> 2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with
> all available servers." but it should catch and try again until the server
> comes up, and then when we write to the queue after the server is up we
> definitely expect the connection to work, but as can be seen in the
> [^failure.log] we are getting:
> {noformat}
> ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed{noformat}
> Line 117 is the first {{jmsTemplate.convertAndSend}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4044:
Description:
I have a unit test for verifying a listener routine I wrote in the event of an
Artemis failure.
With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
connection AFTER the server has finished starting.
{code:java}
@Test
void receiveBatchesTest_resilientToJmsFailure() throws Exception {
var receiveCount = new AtomicInteger(0);
BatchingJmsListenerDefinition listener =
BatchingJmsListenerDefinition.builder(String.class)
.concurrency(1)
.maxBatchSize(10)
.destination("TestQueue")
.jmsTemplate(jmsTemplate)
.target(s -> receiveCount.addAndGet(s.size()))
.receiveTimeout(Duration.ofSeconds(1))
.errorPauseTime(Duration.ofMillis(1))
.build();
embeddedActiveMQ.stop();
registry.registerListener(listener, true);
await().atLeast(Duration.ofMillis(1000));
embeddedActiveMQ.start();
jmsTemplate.convertAndSend("TestQueue", "message1");
jmsTemplate.convertAndSend("TestQueue", "message2");
await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
}{code}
* [^failure.log]
* [^success.log]
* [^success_2_19_1.log]
When {{registerListener}} is called we expect a connection failure and on
2.19.1 we get one there "AMQ219007: Cannot connect to server(s). Tried with all
available servers." but it should catch and try again until the server comes
up, and then when we write to the queue after the server is up we definitely
expect the connection to work, but as can be seen in the [^failure.log] we are
getting:
{noformat}
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
Connection is destroyed{noformat}
Line 117 is the first {{jmsTemplate.convertAndSend}}.
was:
I have a unit test for verifying a listener routine I wrote in the event of an
artemis failure.
With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
connection AFTER the server has finished starting.
{code:java}
@Test
void receiveBatchesTest_resilientToJmsFailure() throws Exception {
var receiveCount = new AtomicInteger(0);
BatchingJmsListenerDefinition listener =
BatchingJmsListenerDefinition.builder(String.class)
.concurrency(1)
.maxBatchSize(10)
.destination("TestQueue")
.jmsTemplate(jmsTemplate)
.target(s -> receiveCount.addAndGet(s.size()))
.receiveTimeout(Duration.ofSeconds(1))
.errorPauseTime(Duration.ofMillis(1))
.build();
embeddedActiveMQ.stop();
registry.registerListener(listener, true);
await().atLeast(Duration.ofMillis(1000));
embeddedActiveMQ.start();
jmsTemplate.convertAndSend("TestQueue", "message1");
jmsTemplate.convertAndSend("TestQueue", "message2");
await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
} {code}
[^failure.log]
[^success.log]
[^success_2_19_1.log]
When registerListener is called we expect a connection failure and on 2.19.1 we
get one there "AMQ219007: Cannot connect to server(s). Tried with all available
servers." but it should catch and try again until the server comes up, and then
when we write to the queue after the server is up we definitely expect the
connection to work, but as can be seen in the failure.log we are getting:
`ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
Connection is destroyed`
line 117 is the first jmsTemplate.convertAndSend.
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an Artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
>
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616624#comment-17616624
]
Justin Bertram commented on ARTEMIS-4044:
-
Do you have a way I could reproduce this? If so, I could perform a {{git
bisect}} to identify the specific commit that introduced the problem. There are
only 65 commits between 2.23.1 and 2.24.0 and certainly none that stand-out as
a potential cause of what you're observing. Here are those commits generated
using {{git log 2.23.1..2.24.0 --oneline --no-merges}}:
{noformat}
897d9beaef [maven-release-plugin] prepare release 2.24.0
3b24211ba9 NO-JIRA update versions.md for next release
631568f020 ARTEMIS-3905 update docs for disabled proxy
b57a1498e8 ARTEMIS-3903 Remove Xalan dependencies
55865ab4b4 Revert "ARTEMIS-3902 Adding reason to Audit Security Message"
db8f530256 ARTEMIS-3902 Adding reason to Audit Security Message
e35758a4d0 ARTEMIS-3901 Improvements on PerfCommand
4737c5c889 ARTEMIS-3901 Fix artemis perf client --durable fails on exception
79daf49105 [maven-release-plugin] prepare for next development iteration
cc4867ccba [maven-release-plugin] prepare release 2.24.0
4513d2f121 NO-JIRA Fix Console QueuesTest
e56b5ff53f ARTEMIS-3840 Core bridges with concurrency > 1 will get removed on
config reload
ab1d7a218e NO-JIRA replace templateFn with htmlTemplate
4974f2a9f0 ARTEMIS-3896 fix tests
14a4446ec1 ARTEMIS-3892 fix test
a49066e6b7 ARTEMIS-3899 improve salt calculation
a2262612ca ARTEMIS-3892 fix tests, add docs
688b894c62 ARTEMIS-3896 clarify logging for transactional ops
695bc5a648 ARTEMIS-3888 make web console detection more robust
ff1fe7f6b5 ARTEMIS-3892 user limits not working with cert auth
ff770d540d ARTEMIS-1964 fix and deprecate getNumberOfMessages() on
AddressControl
8e54a65227 ARTEMIS-3767 Incompatibility on replication between 2.17 and current
version
7bc3b02809 ARTEMIS-3895 - treat properties url with trailing slash as directory
of .properties files and apply in lexical order of name
a0fb174c8f NO-JIRA clarify JmsTemplate warning
0f5bd28e23 ARTEMIS-2894 Small tweak into newInstance call
d3ed11da2a ARTEMIS-3894 - resolve errorprone warn on vargs call
7ee820864b ARTEMIS-3894 - add conversion from string for list - allow core
bridge static connector config via properties
8a6ee31055 NO-JIRA Adding a non failing test on TX send and mirror
ee877e83a6 ARTEMIS-3885: refresh documentation build deps
52c2372053 ARTEMIS-3893: update to commons-configuration 2.8.0
1f2543029c ARTEMIS-3891 - allow TransformerConfig creation via properties
4a4765c39c ARTEMIS-3890 - rework LVQ implementation to ensure all messages get
delivered, replacement of lvq now tied to the deliver loop. Fix issue with
duplicates - bug in LinkedListImpl`
57f48ee146 ARTEMIS-3558 Add broker-connections to config idx
e6e9dfd55f Upgrade jetty to v10
15d839a6b0 ARTEMIS-3820 Fix browsing original queue of AMQP messages
597953b6e2 ARTEMIS-3886 fix CLI operation retry
1c0a6d4091 ARTEMIS-3885: refresh documentation build deps
a207c614e7 ARTEMIS-3883: use same version + junit helpers as rest of build to
start embedded test Directory for example, rather than custom classes
831292e975 ARTEMIS-3883: use common config property to ensure already-aligned
httpclient version remains so
aa14c6e2c8 ARTEMIS-3883: align version of activemq-client used in tests and
examples
8ab792d13c NO-JIRA: update stale Travis config
0ac764324d NO-JIRA: Update github actions
ea498e50e3 NO-JIRA: rework GHA jobs cache config
da38fcce71 NO-JIRA reformat AMQPMirrorControllerTarget
d90179b99c ARTEMIS-3815 proper retry through IOCompletion when message not
found on target queue on Mirror
2f361b1d40 ARTEMIS-3878: Update to Derby test dep to 10.14.2.0
68f6d8263d ARTEMIS-3743 / ARTEMIS-3766 Use ACKReason on Mirror to determine
target operations and fixing Delivering statistics on Mirror
1bcf0f35f8 ARTEMIS-3877: move site javadoc generation into release profile, add
placeholder for regular assembly use, like all the other module content
dc8123dfc3 ARTEMIS-3876: stop extracting native lib files for every module,
only the root where the tests looks for them
3e4013d8ca ARTEMIS-3868 Journal compactor split improvement
2ab0e85db4 ARTEMIS-3874: move/update various bits to allow removing many
test-jar creations and dependencies
2123de415b ARTEMIS-3873 AMQP Broker Conn Encrypted Attrs
d199bf3c8c ARTEMIS-3870: mark -all client deps optional in distribution pom,
avoid passing on clashing/duplicate deps
6d926719f4 ARTEMIS-3863 - allow Role configuration via properties
56e9d9525d ARTEMIS-3864 Removing debug statement
8d29742d40 ARTEMIS-3862 Adding Topic Durable Subscription to
RemoveSubscriptionRaceTest
78587f0a82 NO-JIRA: remove unused methods and related dependencies left from
initial copy plus some other cleanup
fd345f0a03 ARTEMIS-3858 fix navigation from consumer/producer columns of a
session to those consumers/producers
[jira] [Commented] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616604#comment-17616604
]
Stephen Baker commented on ARTEMIS-4044:
To narrow this down a bit further, I was unable to reproduce the issue in
2.23.1 and I did see it in 2.24.0, so it appears to be a regression or a change
of behaviour between those two versions
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: MacOS 12.6
> Corretto JDK 11
> Spring Boot 2.7.4
> artemis.version set to 2.26.0
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: failure.log, success.log, success_2_19_1.log
>
>
> I have a unit test for verifying a listener routine I wrote in the event of
> an artemis failure.
> With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
> connection AFTER the server has finished starting.
>
> {code:java}
> @Test
> void receiveBatchesTest_resilientToJmsFailure() throws Exception {
> var receiveCount = new AtomicInteger(0);
> BatchingJmsListenerDefinition listener =
> BatchingJmsListenerDefinition.builder(String.class)
> .concurrency(1)
> .maxBatchSize(10)
> .destination("TestQueue")
> .jmsTemplate(jmsTemplate)
> .target(s -> receiveCount.addAndGet(s.size()))
> .receiveTimeout(Duration.ofSeconds(1))
> .errorPauseTime(Duration.ofMillis(1))
> .build();
> embeddedActiveMQ.stop();
> registry.registerListener(listener, true);
> await().atLeast(Duration.ofMillis(1000));
> embeddedActiveMQ.start();
> jmsTemplate.convertAndSend("TestQueue", "message1");
> jmsTemplate.convertAndSend("TestQueue", "message2");
> await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
> } {code}
> [^failure.log]
> [^success.log]
> [^success_2_19_1.log]
>
> When registerListener is called we expect a connection failure and on 2.19.1
> we get one there "AMQ219007: Cannot connect to server(s). Tried with all
> available servers." but it should catch and try again until the server comes
> up, and then when we write to the queue after the server is up we definitely
> expect the connection to work, but as can be seen in the failure.log we are
> getting:
> `ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
> Connection is destroyed`
>
> line 117 is the first jmsTemplate.convertAndSend.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4037) Use random alphanumeric strings for MQTTRetainMessageManagerTest
[ https://issues.apache.org/jira/browse/ARTEMIS-4037?focusedWorklogId=816278=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816278 ] ASF GitHub Bot logged work on ARTEMIS-4037: --- Author: ASF GitHub Bot Created on: 12/Oct/22 16:32 Start Date: 12/Oct/22 16:32 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4255: URL: https://github.com/apache/activemq-artemis/pull/4255 Commit 5a42de5fa6ee1b96f6f3e404f5a3d11a702e1776 called my attention to this test. It really needs to be refactored because: - It belongs in the integration-tests module rather than the MQTT protocol module. - It is using a lot of non-standard components (e.g. EmbeddedJMSResource, Awaitility, etc.). - It is overly complicated (e.g. using its own MqttClientService). This commit resolves all those problems. The new implementation is quite a bit different but still equivalent. I reverted the original fix from ARTEMIS-2476 and the test still fails. Issue Time Tracking --- Worklog Id: (was: 816278) Time Spent: 20m (was: 10m) > Use random alphanumeric strings for MQTTRetainMessageManagerTest > > > Key: ARTEMIS-4037 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4037 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.27.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
[
https://issues.apache.org/jira/browse/ARTEMIS-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Baker updated ARTEMIS-4044:
---
Description:
I have a unit test for verifying a listener routine I wrote in the event of an
artemis failure.
With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
connection AFTER the server has finished starting.
{code:java}
@Test
void receiveBatchesTest_resilientToJmsFailure() throws Exception {
var receiveCount = new AtomicInteger(0);
BatchingJmsListenerDefinition listener =
BatchingJmsListenerDefinition.builder(String.class)
.concurrency(1)
.maxBatchSize(10)
.destination("TestQueue")
.jmsTemplate(jmsTemplate)
.target(s -> receiveCount.addAndGet(s.size()))
.receiveTimeout(Duration.ofSeconds(1))
.errorPauseTime(Duration.ofMillis(1))
.build();
embeddedActiveMQ.stop();
registry.registerListener(listener, true);
await().atLeast(Duration.ofMillis(1000));
embeddedActiveMQ.start();
jmsTemplate.convertAndSend("TestQueue", "message1");
jmsTemplate.convertAndSend("TestQueue", "message2");
await().atMost(5, TimeUnit.SECONDS).until(() -> receiveCount.get() == 2);
} {code}
[^failure.log]
[^success.log]
[^success_2_19_1.log]
When registerListener is called we expect a connection failure and on 2.19.1 we
get one there "AMQ219007: Cannot connect to server(s). Tried with all available
servers." but it should catch and try again until the server comes up, and then
when we write to the queue after the server is up we definitely expect the
connection to work, but as can be seen in the failure.log we are getting:
`ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
Connection is destroyed`
line 117 is the first jmsTemplate.convertAndSend.
was:
I have a unit test for verifying a listener routine I wrote in the event of an
artemis failure.
With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
connection AFTER the server has finished starting.
```
{color:#bbb529}@Test
{color}{color:#cc7832}void
{color}{color:#ffc66d}receiveBatchesTest_resilientToJmsFailure{color}()
{color:#cc7832}throws {color}Exception {
{color:#cc7832}var {color}receiveCount = {color:#cc7832}new
{color}AtomicInteger({color:#6897bb}0{color}){color:#cc7832};
{color}{color:#cc7832} {color}BatchingJmsListenerDefinition listener =
BatchingJmsListenerDefinition.builder(String.{color:#cc7832}class{color})
.concurrency({color:#6897bb}1{color})
.maxBatchSize({color:#6897bb}10{color})
.destination({color:#6a8759}"TestQueue"{color})
.jmsTemplate({color:#9876aa}jmsTemplate{color})
.target(s -> {color:#b389c5}receiveCount{color}.addAndGet(s.size()))
.receiveTimeout(Duration.ofSeconds({color:#6897bb}1{color}))
.errorPauseTime(Duration.ofMillis({color:#6897bb}1{color}))
.build(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.stop(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}registry{color}.registerListener(listener{color:#cc7832},
true{color}){color:#cc7832};
{color}{color:#cc7832}
{color}await().atLeast(Duration.ofMillis({color:#6897bb}1000{color})){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.start(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}{color:#9876aa}jmsTemplate{color}.convertAndSend({color:#6a8759}"TestQueue"{color}{color:#cc7832},
{color}{color:#6a8759}"message1"{color}){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}jmsTemplate{color}.convertAndSend({color:#6a8759}"TestQueue"{color}{color:#cc7832},
{color}{color:#6a8759}"message2"{color}){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}await().atMost({color:#6897bb}5{color}{color:#cc7832},
{color}TimeUnit.{color:#9876aa}SECONDS{color}).until(() ->
{color:#b389c5}receiveCount{color}.get() ==
{color:#6897bb}2{color}){color:#cc7832};
{color}}
```
[^failure.log]
[^success.log]
[^success_2_19_1.log]
When registerListener is called we expect a connection failure and on 2.19.1 we
get one there "AMQ219007: Cannot connect to server(s). Tried with all available
servers." but it should catch and try again until the server comes up, and then
when we write to the queue after the server is up we definitely expect the
connection to work, but as can be seen in the failure.log we are getting:
`ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
Connection is destroyed`
line 117 is the first jmsTemplate.convertAndSend.
> AMQ219010: Connection is destroyed with embedded artemis in tests
> -
>
> Key: ARTEMIS-4044
> URL:
[jira] [Created] (ARTEMIS-4044) AMQ219010: Connection is destroyed with embedded artemis in tests
Stephen Baker created ARTEMIS-4044:
--
Summary: AMQ219010: Connection is destroyed with embedded artemis
in tests
Key: ARTEMIS-4044
URL: https://issues.apache.org/jira/browse/ARTEMIS-4044
Project: ActiveMQ Artemis
Issue Type: Bug
Environment: MacOS 12.6
Corretto JDK 11
Spring Boot 2.7.4
artemis.version set to 2.26.0
Reporter: Stephen Baker
Attachments: failure.log, success.log, success_2_19_1.log
I have a unit test for verifying a listener routine I wrote in the event of an
artemis failure.
With artemis-server 2.25.0 and 2.26.0 it is periodically failing to obtain a
connection AFTER the server has finished starting.
```
{color:#bbb529}@Test
{color}{color:#cc7832}void
{color}{color:#ffc66d}receiveBatchesTest_resilientToJmsFailure{color}()
{color:#cc7832}throws {color}Exception {
{color:#cc7832}var {color}receiveCount = {color:#cc7832}new
{color}AtomicInteger({color:#6897bb}0{color}){color:#cc7832};
{color}{color:#cc7832} {color}BatchingJmsListenerDefinition listener =
BatchingJmsListenerDefinition.builder(String.{color:#cc7832}class{color})
.concurrency({color:#6897bb}1{color})
.maxBatchSize({color:#6897bb}10{color})
.destination({color:#6a8759}"TestQueue"{color})
.jmsTemplate({color:#9876aa}jmsTemplate{color})
.target(s -> {color:#b389c5}receiveCount{color}.addAndGet(s.size()))
.receiveTimeout(Duration.ofSeconds({color:#6897bb}1{color}))
.errorPauseTime(Duration.ofMillis({color:#6897bb}1{color}))
.build(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.stop(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}registry{color}.registerListener(listener{color:#cc7832},
true{color}){color:#cc7832};
{color}{color:#cc7832}
{color}await().atLeast(Duration.ofMillis({color:#6897bb}1000{color})){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}embeddedActiveMQ{color}.start(){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}{color:#9876aa}jmsTemplate{color}.convertAndSend({color:#6a8759}"TestQueue"{color}{color:#cc7832},
{color}{color:#6a8759}"message1"{color}){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#9876aa}jmsTemplate{color}.convertAndSend({color:#6a8759}"TestQueue"{color}{color:#cc7832},
{color}{color:#6a8759}"message2"{color}){color:#cc7832};
{color}{color:#cc7832}
{color}{color:#cc7832}
{color}await().atMost({color:#6897bb}5{color}{color:#cc7832},
{color}TimeUnit.{color:#9876aa}SECONDS{color}).until(() ->
{color:#b389c5}receiveCount{color}.get() ==
{color:#6897bb}2{color}){color:#cc7832};
{color}}
```
[^failure.log]
[^success.log]
[^success_2_19_1.log]
When registerListener is called we expect a connection failure and on 2.19.1 we
get one there "AMQ219007: Cannot connect to server(s). Tried with all available
servers." but it should catch and try again until the server comes up, and then
when we write to the queue after the server is up we definitely expect the
connection to work, but as can be seen in the failure.log we are getting:
`ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219010:
Connection is destroyed`
line 117 is the first jmsTemplate.convertAndSend.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4041) Improve criticalIO reporting
[ https://issues.apache.org/jira/browse/ARTEMIS-4041?focusedWorklogId=816217=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816217 ] ASF GitHub Bot logged work on ARTEMIS-4041: --- Author: ASF GitHub Bot Created on: 12/Oct/22 14:50 Start Date: 12/Oct/22 14:50 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4253: URL: https://github.com/apache/activemq-artemis/pull/4253 Issue Time Tracking --- Worklog Id: (was: 816217) Remaining Estimate: 0h Time Spent: 10m > Improve criticalIO reporting > > > Key: ARTEMIS-4041 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4041 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some exceptions are not giving much context. > At the main cause, if for any reason such as a NFS not allocating the file > properly we would throw an IllegalStateException. > We should call FileFactory.onIOError directly in certain places, giving > emphasis to what file had issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4041) Improve criticalIO reporting
[ https://issues.apache.org/jira/browse/ARTEMIS-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616491#comment-17616491 ] ASF subversion and git services commented on ARTEMIS-4041: -- Commit 49d33470f95ef42fa3b870a7da18ffe093c3bb0d in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=49d33470f9 ] ARTEMIS-4041 Improve critical IO reporting > Improve criticalIO reporting > > > Key: ARTEMIS-4041 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4041 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some exceptions are not giving much context. > At the main cause, if for any reason such as a NFS not allocating the file > properly we would throw an IllegalStateException. > We should call FileFactory.onIOError directly in certain places, giving > emphasis to what file had issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4042) DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY env if system property is not set
[ https://issues.apache.org/jira/browse/ARTEMIS-4042?focusedWorklogId=816204=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816204 ] ASF GitHub Bot logged work on ARTEMIS-4042: --- Author: ASF GitHub Bot Created on: 12/Oct/22 14:32 Start Date: 12/Oct/22 14:32 Worklog Time Spent: 10m Work Description: gtully commented on PR #4254: URL: https://github.com/apache/activemq-artemis/pull/4254#issuecomment-1276282532 flaky tests? The pass locally Error: Errors: Error:SecurityTest.testSendManagementWithRole:1721 » ActiveMQNotConnected AMQ219010:... Error:CoreClientOverOneWaySSLTest.testOneWaySSLReloaded:536 » IllegalState AMQ229230... Issue Time Tracking --- Worklog Id: (was: 816204) Time Spent: 20m (was: 10m) > DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY > env if system property is not set > > > Key: ARTEMIS-4042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4042 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.26.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.27.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Following up on ARTEMIS-3488, to avoid expansion of the env var on the > command line, if it is not set as a system property, attempt to read directly > from the environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4043) cleanup some leftover artemis-rest docs and dependency management
[ https://issues.apache.org/jira/browse/ARTEMIS-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616453#comment-17616453 ] ASF subversion and git services commented on ARTEMIS-4043: -- Commit b604545a3c99c0758cda3afe16488170a76c2791 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b604545a3c ] ARTEMIS-4043: remove other doc snippets linking to previously-removed rest.md file, also update URL to point to referenced version > cleanup some leftover artemis-rest docs and dependency management > - > > Key: ARTEMIS-4043 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4043 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.26.0 >Reporter: Robbie Gemmell >Priority: Minor > Fix For: 2.27.0 > > > some cleanup of leftover artemis-rest docs and dependency management, missed > during the original changes in ARTEMIS-3987 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4043) cleanup some leftover artemis-rest docs and dependency management
[ https://issues.apache.org/jira/browse/ARTEMIS-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4043. - Resolution: Fixed > cleanup some leftover artemis-rest docs and dependency management > - > > Key: ARTEMIS-4043 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4043 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.26.0 >Reporter: Robbie Gemmell >Priority: Minor > Fix For: 2.27.0 > > > some cleanup of leftover artemis-rest docs and dependency management, missed > during the original changes in ARTEMIS-3987 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4043) cleanup some leftover artemis-rest docs and dependency management
[
https://issues.apache.org/jira/browse/ARTEMIS-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616448#comment-17616448
]
Robbie Gemmell commented on ARTEMIS-4043:
-
Some related commits:
{noformat}
commit 5b200f84ee7a5958656bc8c722497fc907548fe3
Author: Justin Bertram
Date: Tue Oct 11 10:26:50 2022 -0500
NO-JIRA remove vestigial REST dependencies
{noformat}
{noformat}
commit 5cf84bffbe458a76134692c17243b08e1e12395f
Author: Justin Bertram
Date: Tue Oct 11 11:09:39 2022 -0500
NO-JIRA restore commons-codec dependency; remove REST property
{noformat}
> cleanup some leftover artemis-rest docs and dependency management
> -
>
> Key: ARTEMIS-4043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4043
> Project: ActiveMQ Artemis
> Issue Type: Task
>Affects Versions: 2.26.0
>Reporter: Robbie Gemmell
>Priority: Minor
> Fix For: 2.27.0
>
>
> some cleanup of leftover artemis-rest docs and dependency management, missed
> during the original changes in ARTEMIS-3987
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4043) cleanup some leftover artemis-rest docs and dependency management
Robbie Gemmell created ARTEMIS-4043: --- Summary: cleanup some leftover artemis-rest docs and dependency management Key: ARTEMIS-4043 URL: https://issues.apache.org/jira/browse/ARTEMIS-4043 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.26.0 Reporter: Robbie Gemmell Fix For: 2.27.0 some cleanup of leftover artemis-rest docs and dependency management, missed during the original changes in ARTEMIS-3987 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9118) jms consumer may hang if jms.prefetchPolicy.all=0
[ https://issues.apache.org/jira/browse/AMQ-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon updated AMQ-9118: Attachment: MqTest2.java > jms consumer may hang if jms.prefetchPolicy.all=0 > -- > > Key: AMQ-9118 > URL: https://issues.apache.org/jira/browse/AMQ-9118 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.16.5 >Reporter: Gordon >Priority: Major > Attachments: MqTest2.java > > > > I have an activemq broker using jdbc datasource and client application using > failover tcp connection with parameter jms.prefetchPolicy.all=0. If > connection to database is not stable, client may hang indefinitely. > This happens in this scenario: > # There is a jms connection using failover tcp transport. Session is using > CLIENT_ACKNOWLEDGE. > # Jms consumer calls receive - it sends pull message request to the broker. > # broker sends message to the consumer. > # client application starts processing of the message. > # network failure, broker looses connection to the database. > # broker stops tcp transport. > # client application finish processing of the message, but jms consumer > fails to acknowledge message because broker is not available. > # network restores, broker restarts tcp transport. > # jms consumer restores connection to the broker and sends pull message > request. > # Broker sends the SAME message to the consumer because it was not > acknowledged. > # ActiveMQMessageConsumer detects message as duplicate and DROPS it, writing > "suppressing duplicate delivery on connection, poison acking: > MessageDispatch" in the log. > # consumer continue to wait a message. It hangs forever. > > This issue happens when jms.prefetchPolicy.all=0 - when client pulls messages > from the broker instead of the broker pushing them to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9118) jms consumer may hang if jms.prefetchPolicy.all=0
[ https://issues.apache.org/jira/browse/AMQ-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon updated AMQ-9118: Attachment: (was: MqTest2.java) > jms consumer may hang if jms.prefetchPolicy.all=0 > -- > > Key: AMQ-9118 > URL: https://issues.apache.org/jira/browse/AMQ-9118 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.16.5 >Reporter: Gordon >Priority: Major > Attachments: MqTest2.java > > > > I have an activemq broker using jdbc datasource and client application using > failover tcp connection with parameter jms.prefetchPolicy.all=0. If > connection to database is not stable, client may hang indefinitely. > This happens in this scenario: > # There is a jms connection using failover tcp transport. Session is using > CLIENT_ACKNOWLEDGE. > # Jms consumer calls receive - it sends pull message request to the broker. > # broker sends message to the consumer. > # client application starts processing of the message. > # network failure, broker looses connection to the database. > # broker stops tcp transport. > # client application finish processing of the message, but jms consumer > fails to acknowledge message because broker is not available. > # network restores, broker restarts tcp transport. > # jms consumer restores connection to the broker and sends pull message > request. > # Broker sends the SAME message to the consumer because it was not > acknowledged. > # ActiveMQMessageConsumer detects message as duplicate and DROPS it, writing > "suppressing duplicate delivery on connection, poison acking: > MessageDispatch" in the log. > # consumer continue to wait a message. It hangs forever. > > This issue happens when jms.prefetchPolicy.all=0 - when client pulls messages > from the broker instead of the broker pushing them to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9118) jms consumer may hang if jms.prefetchPolicy.all=0
[ https://issues.apache.org/jira/browse/AMQ-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616401#comment-17616401 ] Gordon commented on AMQ-9118: - Example client application - MqTest2.java. Connection to the database can be emulated using "socat" proxy: socat TCP-LISTEN:15432,fork TCP:127.0.0.1:5432 where 5432 - postgresql port, 15432 - port broker connects to. Killing socat kills connection to DB. > jms consumer may hang if jms.prefetchPolicy.all=0 > -- > > Key: AMQ-9118 > URL: https://issues.apache.org/jira/browse/AMQ-9118 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.16.5 >Reporter: Gordon >Priority: Major > Attachments: MqTest2.java > > > > I have an activemq broker using jdbc datasource and client application using > failover tcp connection with parameter jms.prefetchPolicy.all=0. If > connection to database is not stable, client may hang indefinitely. > This happens in this scenario: > # There is a jms connection using failover tcp transport. Session is using > CLIENT_ACKNOWLEDGE. > # Jms consumer calls receive - it sends pull message request to the broker. > # broker sends message to the consumer. > # client application starts processing of the message. > # network failure, broker looses connection to the database. > # broker stops tcp transport. > # client application finish processing of the message, but jms consumer > fails to acknowledge message because broker is not available. > # network restores, broker restarts tcp transport. > # jms consumer restores connection to the broker and sends pull message > request. > # Broker sends the SAME message to the consumer because it was not > acknowledged. > # ActiveMQMessageConsumer detects message as duplicate and DROPS it, writing > "suppressing duplicate delivery on connection, poison acking: > MessageDispatch" in the log. > # consumer continue to wait a message. It hangs forever. > > This issue happens when jms.prefetchPolicy.all=0 - when client pulls messages > from the broker instead of the broker pushing them to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9118) jms consumer may hang if jms.prefetchPolicy.all=0
[ https://issues.apache.org/jira/browse/AMQ-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon updated AMQ-9118: Attachment: MqTest2.java > jms consumer may hang if jms.prefetchPolicy.all=0 > -- > > Key: AMQ-9118 > URL: https://issues.apache.org/jira/browse/AMQ-9118 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.16.5 >Reporter: Gordon >Priority: Major > Attachments: MqTest2.java > > > > I have an activemq broker using jdbc datasource and client application using > failover tcp connection with parameter jms.prefetchPolicy.all=0. If > connection to database is not stable, client may hang indefinitely. > This happens in this scenario: > # There is a jms connection using failover tcp transport. Session is using > CLIENT_ACKNOWLEDGE. > # Jms consumer calls receive - it sends pull message request to the broker. > # broker sends message to the consumer. > # client application starts processing of the message. > # network failure, broker looses connection to the database. > # broker stops tcp transport. > # client application finish processing of the message, but jms consumer > fails to acknowledge message because broker is not available. > # network restores, broker restarts tcp transport. > # jms consumer restores connection to the broker and sends pull message > request. > # Broker sends the SAME message to the consumer because it was not > acknowledged. > # ActiveMQMessageConsumer detects message as duplicate and DROPS it, writing > "suppressing duplicate delivery on connection, poison acking: > MessageDispatch" in the log. > # consumer continue to wait a message. It hangs forever. > > This issue happens when jms.prefetchPolicy.all=0 - when client pulls messages > from the broker instead of the broker pushing them to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9118) jms consumer may hang if jms.prefetchPolicy.all=0
Gordon created AMQ-9118: --- Summary: jms consumer may hang if jms.prefetchPolicy.all=0 Key: AMQ-9118 URL: https://issues.apache.org/jira/browse/AMQ-9118 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.16.5 Reporter: Gordon I have an activemq broker using jdbc datasource and client application using failover tcp connection with parameter jms.prefetchPolicy.all=0. If connection to database is not stable, client may hang indefinitely. This happens in this scenario: # There is a jms connection using failover tcp transport. Session is using CLIENT_ACKNOWLEDGE. # Jms consumer calls receive - it sends pull message request to the broker. # broker sends message to the consumer. # client application starts processing of the message. # network failure, broker looses connection to the database. # broker stops tcp transport. # client application finish processing of the message, but jms consumer fails to acknowledge message because broker is not available. # network restores, broker restarts tcp transport. # jms consumer restores connection to the broker and sends pull message request. # Broker sends the SAME message to the consumer because it was not acknowledged. # ActiveMQMessageConsumer detects message as duplicate and DROPS it, writing "suppressing duplicate delivery on connection, poison acking: MessageDispatch" in the log. # consumer continue to wait a message. It hangs forever. This issue happens when jms.prefetchPolicy.all=0 - when client pulls messages from the broker instead of the broker pushing them to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816140=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816140
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 12:41
Start Date: 12/Oct/22 12:41
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r981040625
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/QueueControlTest.java:
##
@@ -441,6 +446,84 @@ public void testGetConsumerJSON() throws Exception {
session.deleteQueue(queue);
}
+ @Test
+ public void testGetConsumerWithMessagesJSON() throws Exception {
+ SimpleString address = RandomUtil.randomSimpleString();
+ SimpleString queue = RandomUtil.randomSimpleString();
+
+ session.createQueue(new
QueueConfiguration(queue).setAddress(address).setDurable(durable));
+
+ QueueControl queueControl = createManagementControl(address, queue);
+
+ ClientProducer producer = session.createProducer(address);
+
+ for (int i = 0; i < 10; i++) {
+ producer.send(session.createMessage(true));
+ }
+
+ Wait.assertEquals(0, () -> queueControl.getConsumerCount());
+
+ ClientConsumer consumer = session.createConsumer(queue);
+ Wait.assertEquals(1, () -> queueControl.getConsumerCount());
+
+ session.start();
+
+ ClientMessage clientMessage = null;
+
+ int size = 0;
+ for (int i = 0; i < 5; i++) {
+ clientMessage = consumer.receiveImmediate();
+ size += clientMessage.getEncodeSize();
+ }
+
+ JsonArray obj =
JsonUtil.readJsonArray(queueControl.listConsumersAsJSON());
+
+ assertEquals(1, obj.size());
+
+ Wait.assertEquals(5, () ->
JsonUtil.readJsonArray(queueControl.listConsumersAsJSON()).get(0).asJsonObject().getInt(ConsumerField.MESSAGES_IN_TRANSIT.getName()));
+
+ obj = JsonUtil.readJsonArray(queueControl.listConsumersAsJSON());
+
+ JsonObject jsonObject = obj.get(0).asJsonObject();
+
+ assertEquals(5,
jsonObject.getInt(ConsumerField.MESSAGES_IN_TRANSIT.getName()));
+
+ assertEquals(size,
jsonObject.getInt(ConsumerField.MESSAGES_IN_TRANSIT_SIZE.getName()));
+
+ assertEquals(5,
jsonObject.getInt(ConsumerField.MESSAGES_DELIVERED.getName()));
+
+ assertEquals(size,
jsonObject.getInt(ConsumerField.MESSAGES_DELIVERED_SIZE.getName()));
+
+ assertEquals(0,
jsonObject.getInt(ConsumerField.MESSAGES_ACKNOWLEDGED.getName()));
+
+ //we cant assume an elapseed time to only checking for its existence
+
assertNotNull(jsonObject.getInt(ConsumerField.LAST_DELIVERED_TIME.getName()));
+
+ assertEquals( 0,
jsonObject.getInt(ConsumerField.LAST_ACKNOWLEDGED_TIME.getName()));
Review Comment:
If these are going to be a timestamp they can be asserted to be a value
within a fairly specific delta during the test itself, and also their values
relative to each other. E.g ensure they are in flight, then a further 1ms delay
before acking would mean the 2 values also have to differ by at least that
much, but be after the point the test started, and you can then also put a
narrow delta for the ack time value by using the time you called it + allowance.
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java:
##
@@ -2342,8 +2331,8 @@ public Pair>
getAddressAndRoutingTypes(Simple
@Override
public void addProducer(ServerProducer serverProducer) {
serverProducer.setSessionID(getName());
- serverProducer.setConnectionID(getConnectionID().toString());
- producers.put(serverProducer.getID(), serverProducer);
+ serverProducer.setConnectionID(getConnectionID() != null ?
getConnectionID().toString() : null);
+ producers.put(serverProducer.getAddress(), serverProducer);
Review Comment:
This makes the addition use getAddress() however the removeProducer() method
below it is still using the 'ID' value which will likely mismatch the
add+remove operations and so could lead to retention.
Also, by using getAddress() here, it might mean the producer addition here
may not align with the producer lookup later in doSend for an anonymous
producer (and perhaps also producer to FQQN?), meaning a new address-specific
'synthetic producer' value could get created in doSend() per-address and
leading to multiple ServerProducerImpl entries for a single actual producer,
throwing off the producer count and also making the metric values wrong for the
initial actual producer (since the metrics would be assigned to the 'synthetic
duplicates' per-address). The change in ActiveMQPacketHandler.java would
presumably have been to stop [part of] this problem manifesting for Core.
[jira] [Work logged] (ARTEMIS-4042) DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY env if system property is not set
[ https://issues.apache.org/jira/browse/ARTEMIS-4042?focusedWorklogId=816099=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816099 ] ASF GitHub Bot logged work on ARTEMIS-4042: --- Author: ASF GitHub Bot Created on: 12/Oct/22 11:30 Start Date: 12/Oct/22 11:30 Worklog Time Spent: 10m Work Description: gtully opened a new pull request, #4254: URL: https://github.com/apache/activemq-artemis/pull/4254 … is not set Issue Time Tracking --- Worklog Id: (was: 816099) Remaining Estimate: 0h Time Spent: 10m > DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY > env if system property is not set > > > Key: ARTEMIS-4042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4042 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.26.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.27.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Following up on ARTEMIS-3488, to avoid expansion of the env var on the > command line, if it is not set as a system property, attempt to read directly > from the environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4042) DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY env if system property is not set
Gary Tully created ARTEMIS-4042: --- Summary: DefaultSensitiveStringCodec - read ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY env if system property is not set Key: ARTEMIS-4042 URL: https://issues.apache.org/jira/browse/ARTEMIS-4042 Project: ActiveMQ Artemis Issue Type: Improvement Components: Configuration Affects Versions: 2.26.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.27.0 Following up on ARTEMIS-3488, to avoid expansion of the env var on the command line, if it is not set as a system property, attempt to read directly from the environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816068=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816068
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 10:06
Start Date: 12/Oct/22 10:06
Worklog Time Spent: 10m
Work Description: andytaylor commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r993261491
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/ActiveMQServerControlTest.java:
##
@@ -3586,6 +4115,14 @@ public void testListConsumers() throws Exception {
Assert.assertNotEquals("localAddress", "",
jsonConsumer.getString("localAddress"));
Assert.assertNotEquals("remoteAddress", "",
jsonConsumer.getString("remoteAddress"));
Assert.assertNotEquals("creationTime", "",
jsonConsumer.getString("creationTime"));
+ Assert.assertNotEquals("messagesInTransit", "",
jsonConsumer.getString("messagesInTransit"));
+ Assert.assertNotEquals("messagesInTransitSize", "",
jsonConsumer.getString("messagesInTransitSize"));
+ Assert.assertNotEquals("messageDelivered", "",
jsonConsumer.getString("messageDelivered"));
+ Assert.assertNotEquals("messagesDeliveredSize", "",
jsonConsumer.getString("messagesDeliveredSize"));
+ Assert.assertNotEquals("messagesAcknowledged", "",
jsonConsumer.getString("messagesAcknowledged"));
+ Assert.assertNotEquals("lastDeliveredTimeElapsed", "",
jsonConsumer.getString("lastDeliveredTimeElapsed"));
+ Assert.assertNotEquals("lastAcknowledgedTimeElapsed", "",
jsonConsumer.getString("lastAcknowledgedTimeElapsed"));
Review Comment:
fixed
Issue Time Tracking
---
Worklog Id: (was: 816068)
Time Spent: 3h 40m (was: 3.5h)
> Improve consumer/producer metrics
> -
>
> Key: ARTEMIS-3875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3875
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> adding the following metrics:
>
> for the Consumer and the methods listAllConsumersAsJSON on server and queue
> mbeans:
> messagesInTransit - number of Messages out for delivery which have not yet
> been acknowledged
> messagesInTransitSize - The total size of Messages out for delivery which
> have not yet been acknowledged
> messagesDelivered - Number of messages delivered
> messagesDeliveredSize' - total size of messages delivered
> messagesAcknowledged - total number of Messages Acknowledged
> messagesAcknowledgedAwaitingCommit - Total number of messages in a
> transaction that are acknowledged but awaiting a commit
> lastDeliveredTime - The time in milliseconds of the last message delivered
> lastAcknowledgedTime - The time in milliseconds of the last message
> acknowledged
>
> for the Producer add to the listProducers and listproducersasJSON mbean
> methods
> msgSent - The number of messages sent by a producer
> msgSizeSent - The total size of messages sent by a producer
> lastUUIDSent - The UUID of the last message sent
>
> The producer views are currently quite broken, different protocols show
> different producer info and number of producers, this is because in core we
> add a single producer per session which means you get 2 for ecey core
> session. Im changing this to be a producer for every address sent to. For
> normal producers this will now show s single producer for every protocol, for
> anon producers this will show a producer for every address sent to. For DOS
> protection this will max on 100 producers and they will also be torn down
> when the session is closed.
>
> Ive also move the use of targetAddressInfos into the server producer for
> consistencey.
>
> Other improvements
> * Consolidate the names used by the different methods to be more consistent
> and referenced by static variables.
> * use statics in all the tests
> * add tests for different message count scenarios
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816067=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816067
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 10:06
Start Date: 12/Oct/22 10:06
Worklog Time Spent: 10m
Work Description: andytaylor commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r993261215
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/ActiveMQServerControlTest.java:
##
@@ -2631,7 +2633,7 @@ public void testListConsumersAsJSON() throws Exception {
Assert.assertEquals(queueName.toString(), first.getString("queueName"));
Assert.assertEquals(false, first.getBoolean("browseOnly"));
Assert.assertTrue(first.getJsonNumber("creationTime").longValue() > 0);
- Assert.assertEquals(0,
first.getJsonNumber("deliveringCount").longValue());
+ Assert.assertEquals(0,
first.getJsonNumber("messagesInTransit").longValue());
Review Comment:
testadded
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java:
##
@@ -2242,13 +2246,14 @@ public synchronized RoutingStatus doSend(final
Transaction tx,
result = postOffice.route(msg, routingContext, direct);
- Pair value =
targetAddressInfos.get(msg.getAddressSimpleString());
+ Pair value =
targetAddressInfos.get(msg.getAddressSimpleString());
if (value == null) {
-targetAddressInfos.put(msg.getAddressSimpleString(), new
Pair<>(msg.getUserID(), new AtomicLong(1)));
+targetAddressInfos.put(msg.getAddressSimpleString(), new
Pair<>(msg.getUserID(), new TargetAddressInfo()));
Review Comment:
fixed
Issue Time Tracking
---
Worklog Id: (was: 816067)
Time Spent: 3.5h (was: 3h 20m)
> Improve consumer/producer metrics
> -
>
> Key: ARTEMIS-3875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3875
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> adding the following metrics:
>
> for the Consumer and the methods listAllConsumersAsJSON on server and queue
> mbeans:
> messagesInTransit - number of Messages out for delivery which have not yet
> been acknowledged
> messagesInTransitSize - The total size of Messages out for delivery which
> have not yet been acknowledged
> messagesDelivered - Number of messages delivered
> messagesDeliveredSize' - total size of messages delivered
> messagesAcknowledged - total number of Messages Acknowledged
> messagesAcknowledgedAwaitingCommit - Total number of messages in a
> transaction that are acknowledged but awaiting a commit
> lastDeliveredTime - The time in milliseconds of the last message delivered
> lastAcknowledgedTime - The time in milliseconds of the last message
> acknowledged
>
> for the Producer add to the listProducers and listproducersasJSON mbean
> methods
> msgSent - The number of messages sent by a producer
> msgSizeSent - The total size of messages sent by a producer
> lastUUIDSent - The UUID of the last message sent
>
> The producer views are currently quite broken, different protocols show
> different producer info and number of producers, this is because in core we
> add a single producer per session which means you get 2 for ecey core
> session. Im changing this to be a producer for every address sent to. For
> normal producers this will now show s single producer for every protocol, for
> anon producers this will show a producer for every address sent to. For DOS
> protection this will max on 100 producers and they will also be torn down
> when the session is closed.
>
> Ive also move the use of targetAddressInfos into the server producer for
> consistencey.
>
> Other improvements
> * Consolidate the names used by the different methods to be more consistent
> and referenced by static variables.
> * use statics in all the tests
> * add tests for different message count scenarios
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816065
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 10:05
Start Date: 12/Oct/22 10:05
Worklog Time Spent: 10m
Work Description: andytaylor commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r993260733
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/TargetAddressInfo.java:
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.server.impl;
+
+
+import java.util.concurrent.atomic.AtomicLong;
+
+class TargetAddressInfo {
+ private AtomicLong messagesSent = new AtomicLong(1);
+
+ private AtomicLong messagesSizeSent = new AtomicLong(0);
Review Comment:
fixed
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java:
##
@@ -2752,7 +2754,24 @@ public String listAllConsumersAsJSON() throws Exception {
}
private JsonObject toJSONObject(ServerConsumer consumer) throws Exception {
- JsonObjectBuilder obj =
JsonLoader.createObjectBuilder().add("consumerID",
consumer.getID()).add("connectionID",
consumer.getConnectionID().toString()).add("sessionID",
consumer.getSessionID()).add("queueName",
consumer.getQueue().getName().toString()).add("browseOnly",
consumer.isBrowseOnly()).add("creationTime",
consumer.getCreationTime()).add("deliveringCount",
consumer.getDeliveringMessages().size());
+ List deliveringMessages =
consumer.getDeliveringMessages();
+ JsonObjectBuilder obj = JsonLoader.createObjectBuilder()
+.add(ConsumerField.ID.getAlternativeName(), consumer.getID())
+.add(ConsumerField.CONNECTION.getAlternativeName(),
consumer.getConnectionID().toString())
+.add(ConsumerField.SESSION.getAlternativeName(),
consumer.getSessionID())
+.add(ConsumerField.QUEUE.getAlternativeName(),
consumer.getQueue().getName().toString())
+.add(ConsumerField.BROWSE_ONLY.getName(), consumer.isBrowseOnly())
+.add(ConsumerField.CREATION_TIME.getName(),
consumer.getCreationTime())
+// deliveringCount is renamed as MESSAGES_IN_TRANSIT but left in
json for backward compatibility
+.add(ConsumerField.MESSAGES_IN_TRANSIT.getAlternativeName(),
consumer.getMessagesInTransit())
+.add(ConsumerField.MESSAGES_IN_TRANSIT.getName(),
consumer.getMessagesInTransit())
Review Comment:
test added
Issue Time Tracking
---
Worklog Id: (was: 816065)
Time Spent: 3h 10m (was: 3h)
> Improve consumer/producer metrics
> -
>
> Key: ARTEMIS-3875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3875
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> adding the following metrics:
>
> for the Consumer and the methods listAllConsumersAsJSON on server and queue
> mbeans:
> messagesInTransit - number of Messages out for delivery which have not yet
> been acknowledged
> messagesInTransitSize - The total size of Messages out for delivery which
> have not yet been acknowledged
> messagesDelivered - Number of messages delivered
> messagesDeliveredSize' - total size of messages delivered
> messagesAcknowledged - total number of Messages Acknowledged
> messagesAcknowledgedAwaitingCommit - Total number of messages in a
> transaction that are acknowledged but awaiting a commit
> lastDeliveredTime - The time in milliseconds of the last message delivered
> lastAcknowledgedTime - The time in milliseconds of the last message
> acknowledged
>
> for the Producer add to the listProducers and listproducersasJSON mbean
> methods
> msgSent - The number of messages sent by a
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816064=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816064
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 10:05
Start Date: 12/Oct/22 10:05
Worklog Time Spent: 10m
Work Description: andytaylor commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r993260431
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AbstractControl.java:
##
@@ -50,8 +51,15 @@ public AbstractControl(final Class clazz, final
StorageManager storageManager
this.storageManager = storageManager;
}
+ public long getLastDeliveredTimeElapsed(ServerConsumer consumer) {
+ long currentTime = System.currentTimeMillis();
+ return consumer.getLastDeliveredTime() == 0 ? 0 : currentTime -
consumer.getLastDeliveredTime();
Review Comment:
Ive reverted to just passing back the current time as per @gtully suggested
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerConsumerImpl.java:
##
@@ -506,8 +510,10 @@ public void proceedDeliver(MessageReference reference)
throws Exception {
// The deliverer was prepared during handle, as we can't have more
than one pending large message
// as it would return busy if there is anything pending
largeMessageDeliverer.deliver();
+//lastDeliveredTime = System.currentTimeMillis();
Review Comment:
fixed
Issue Time Tracking
---
Worklog Id: (was: 816064)
Time Spent: 3h (was: 2h 50m)
> Improve consumer/producer metrics
> -
>
> Key: ARTEMIS-3875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3875
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> adding the following metrics:
>
> for the Consumer and the methods listAllConsumersAsJSON on server and queue
> mbeans:
> messagesInTransit - number of Messages out for delivery which have not yet
> been acknowledged
> messagesInTransitSize - The total size of Messages out for delivery which
> have not yet been acknowledged
> messagesDelivered - Number of messages delivered
> messagesDeliveredSize' - total size of messages delivered
> messagesAcknowledged - total number of Messages Acknowledged
> messagesAcknowledgedAwaitingCommit - Total number of messages in a
> transaction that are acknowledged but awaiting a commit
> lastDeliveredTime - The time in milliseconds of the last message delivered
> lastAcknowledgedTime - The time in milliseconds of the last message
> acknowledged
>
> for the Producer add to the listProducers and listproducersasJSON mbean
> methods
> msgSent - The number of messages sent by a producer
> msgSizeSent - The total size of messages sent by a producer
> lastUUIDSent - The UUID of the last message sent
>
> The producer views are currently quite broken, different protocols show
> different producer info and number of producers, this is because in core we
> add a single producer per session which means you get 2 for ecey core
> session. Im changing this to be a producer for every address sent to. For
> normal producers this will now show s single producer for every protocol, for
> anon producers this will show a producer for every address sent to. For DOS
> protection this will max on 100 producers and they will also be torn down
> when the session is closed.
>
> Ive also move the use of targetAddressInfos into the server producer for
> consistencey.
>
> Other improvements
> * Consolidate the names used by the different methods to be more consistent
> and referenced by static variables.
> * use statics in all the tests
> * add tests for different message count scenarios
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3875) Improve consumer/producer metrics
[
https://issues.apache.org/jira/browse/ARTEMIS-3875?focusedWorklogId=816066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816066
]
ASF GitHub Bot logged work on ARTEMIS-3875:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 10:05
Start Date: 12/Oct/22 10:05
Worklog Time Spent: 10m
Work Description: andytaylor commented on code in PR #4183:
URL: https://github.com/apache/activemq-artemis/pull/4183#discussion_r993261063
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerConsumerImpl.java:
##
@@ -506,8 +510,10 @@ public void proceedDeliver(MessageReference reference)
throws Exception {
// The deliverer was prepared during handle, as we can't have more
than one pending large message
// as it would return busy if there is anything pending
largeMessageDeliverer.deliver();
+//lastDeliveredTime = System.currentTimeMillis();
} else {
deliverStandardMessage(reference, message);
+ // lastDeliveredTime = System.currentTimeMillis();
Review Comment:
fixed
Issue Time Tracking
---
Worklog Id: (was: 816066)
Time Spent: 3h 20m (was: 3h 10m)
> Improve consumer/producer metrics
> -
>
> Key: ARTEMIS-3875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3875
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> adding the following metrics:
>
> for the Consumer and the methods listAllConsumersAsJSON on server and queue
> mbeans:
> messagesInTransit - number of Messages out for delivery which have not yet
> been acknowledged
> messagesInTransitSize - The total size of Messages out for delivery which
> have not yet been acknowledged
> messagesDelivered - Number of messages delivered
> messagesDeliveredSize' - total size of messages delivered
> messagesAcknowledged - total number of Messages Acknowledged
> messagesAcknowledgedAwaitingCommit - Total number of messages in a
> transaction that are acknowledged but awaiting a commit
> lastDeliveredTime - The time in milliseconds of the last message delivered
> lastAcknowledgedTime - The time in milliseconds of the last message
> acknowledged
>
> for the Producer add to the listProducers and listproducersasJSON mbean
> methods
> msgSent - The number of messages sent by a producer
> msgSizeSent - The total size of messages sent by a producer
> lastUUIDSent - The UUID of the last message sent
>
> The producer views are currently quite broken, different protocols show
> different producer info and number of producers, this is because in core we
> add a single producer per session which means you get 2 for ecey core
> session. Im changing this to be a producer for every address sent to. For
> normal producers this will now show s single producer for every protocol, for
> anon producers this will show a producer for every address sent to. For DOS
> protection this will max on 100 producers and they will also be torn down
> when the session is closed.
>
> Ive also move the use of targetAddressInfos into the server producer for
> consistencey.
>
> Other improvements
> * Consolidate the names used by the different methods to be more consistent
> and referenced by static variables.
> * use statics in all the tests
> * add tests for different message count scenarios
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4025) properties config - provide error status for invalid properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4025?focusedWorklogId=816045=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816045 ] ASF GitHub Bot logged work on ARTEMIS-4025: --- Author: ASF GitHub Bot Created on: 12/Oct/22 09:14 Start Date: 12/Oct/22 09:14 Worklog Time Spent: 10m Work Description: gtully commented on PR #4241: URL: https://github.com/apache/activemq-artemis/pull/4241#issuecomment-1275847541 thanks for all the feedback, appreciate your time. Issue Time Tracking --- Worklog Id: (was: 816045) Time Spent: 1h 40m (was: 1.5h) > properties config - provide error status for invalid properties > > > Key: ARTEMIS-4025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4025 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.26.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.27.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > following up on the availability of a [status json|ARTEMIS-4007] - trap any > errors from bean util property failure to apply, for any in invalid property. > Currently all failures to find setters are silently ignored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4025) properties config - provide error status for invalid properties
[
https://issues.apache.org/jira/browse/ARTEMIS-4025?focusedWorklogId=816044=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816044
]
ASF GitHub Bot logged work on ARTEMIS-4025:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 09:12
Start Date: 12/Oct/22 09:12
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4241:
URL: https://github.com/apache/activemq-artemis/pull/4241#discussion_r993207211
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerStatus.java:
##
@@ -0,0 +1,81 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.core.server.impl;
+
+
+import java.util.HashMap;
+
+import org.apache.activemq.artemis.api.core.JsonUtil;
+import org.apache.activemq.artemis.api.core.SimpleString;
+import org.apache.activemq.artemis.json.JsonObject;
+import org.apache.activemq.artemis.json.JsonObjectBuilder;
+import org.apache.activemq.artemis.utils.JsonLoader;
+
+public class ServerStatus {
+
+ private static final ServerStatus instance = new ServerStatus();
+
+ public static synchronized ServerStatus getInstanceFor(ActiveMQServerImpl
activeMQServer) {
+ if (instance.server == null) {
+ instance.server = activeMQServer;
+ instance.immutableStateValues.put("version",
instance.server.getVersion().getFullVersion());
Review Comment:
I am going to leave the simple attributes, if we build up this some more,
those names could be inferred.
Issue Time Tracking
---
Worklog Id: (was: 816044)
Time Spent: 1.5h (was: 1h 20m)
> properties config - provide error status for invalid properties
>
>
> Key: ARTEMIS-4025
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4025
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.26.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.27.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> following up on the availability of a [status json|ARTEMIS-4007] - trap any
> errors from bean util property failure to apply, for any in invalid property.
> Currently all failures to find setters are silently ignored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4025) properties config - provide error status for invalid properties
[
https://issues.apache.org/jira/browse/ARTEMIS-4025?focusedWorklogId=816042=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816042
]
ASF GitHub Bot logged work on ARTEMIS-4025:
---
Author: ASF GitHub Bot
Created on: 12/Oct/22 09:10
Start Date: 12/Oct/22 09:10
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4241:
URL: https://github.com/apache/activemq-artemis/pull/4241#discussion_r993204103
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java:
##
@@ -611,13 +614,24 @@ public void setProperties(String
fileUrltoBrokerProperties) {
propertiesFileUrl = fileUrltoBrokerProperties;
}
+ @Override
+ public String getStatus() {
+ return serverStatus.asJson();
+ }
+
+ @Override
+ public void updateStatus(String component, String statusJson) {
+ serverStatus.update(component, statusJson);
+ }
+
private void internalStart() throws Exception {
if (state != SERVER_STATE.STOPPED) {
logger.debug("Server already started!");
return;
}
configuration.parseProperties(propertiesFileUrl);
+ updateStatus("configuration", configuration.getStatus());
Review Comment:
agree, thanks.
Issue Time Tracking
---
Worklog Id: (was: 816042)
Time Spent: 1h 20m (was: 1h 10m)
> properties config - provide error status for invalid properties
>
>
> Key: ARTEMIS-4025
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4025
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.26.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.27.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> following up on the availability of a [status json|ARTEMIS-4007] - trap any
> errors from bean util property failure to apply, for any in invalid property.
> Currently all failures to find setters are silently ignored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4018) Existing paged messages not delivered to consumers after upgrade
[
https://issues.apache.org/jira/browse/ARTEMIS-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Machon closed ARTEMIS-4018.
-
Resolution: Invalid
> Existing paged messages not delivered to consumers after upgrade
>
>
> Key: ARTEMIS-4018
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4018
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: SUSE Linux Enterprise Server 15 SP3
> JAVA_ARGS="-XX:+PrintClassHistogram -XX:+UseG1GC -XX:+UseStringDeduplication
> -Xms512M -Xmx4G -Dhawtio.disableProxy=true -Dhawtio.realm=activemq
> -Dhawtio.offline=true
> -Dhawtio.rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal
> -Djolokia.policyLocation=${ARTEMIS_INSTANCE_ETC_URI}jolokia-access.xml "
>Reporter: Peter Machon
>Priority: Major
>
> After upgrading from version 2.22.0 to 2.25.0 we were facing a situation
> where messages, already queued or paged before the upgrade are not delivered
> to consumers. New messages, arriving at the broker after the upgrade were
> handled normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4018) Existing paged messages not delivered to consumers after upgrade
[
https://issues.apache.org/jira/browse/ARTEMIS-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616282#comment-17616282
]
Peter Machon commented on ARTEMIS-4018:
---
I think, the issue was actually due to our client not acknowledging messages
correctly. Will close. Sorry for the confusion.
> Existing paged messages not delivered to consumers after upgrade
>
>
> Key: ARTEMIS-4018
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4018
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Environment: SUSE Linux Enterprise Server 15 SP3
> JAVA_ARGS="-XX:+PrintClassHistogram -XX:+UseG1GC -XX:+UseStringDeduplication
> -Xms512M -Xmx4G -Dhawtio.disableProxy=true -Dhawtio.realm=activemq
> -Dhawtio.offline=true
> -Dhawtio.rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal
> -Djolokia.policyLocation=${ARTEMIS_INSTANCE_ETC_URI}jolokia-access.xml "
>Reporter: Peter Machon
>Priority: Major
>
> After upgrading from version 2.22.0 to 2.25.0 we were facing a situation
> where messages, already queued or paged before the upgrade are not delivered
> to consumers. New messages, arriving at the broker after the upgrade were
> handled normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
