[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Description:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a
service(s) removed via .cfg delete or osgi service shutdown lifecycle).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here.. due to concurrent modification on the collection
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
was:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a
service(s) removed via .cfg delete or osgi service shutdown lifecycle).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a
> service(s) removed via .cfg delete or osgi service shutdown lifecycle).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here.. due to concurrent modification on the collection
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Priority: Minor (was: Major)
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Minor
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a
> service(s) removed via .cfg delete or osgi service shutdown lifecycle).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here.. due to concurrent modification on the _brokers_
> collection
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Description:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a
service(s) removed via .cfg delete or osgi service shutdown lifecycle).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here.. due to concurrent modification on the _brokers_
collection
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
was:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a
service(s) removed via .cfg delete or osgi service shutdown lifecycle).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here.. due to concurrent modification on the collection
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a
> service(s) removed via .cfg delete or osgi service shutdown lifecycle).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here.. due to concurrent modification on the _brokers_
> collection
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich reassigned AMQ-9376:
---
Assignee: Matt Pavlovich
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a
> service(s) removed via .cfg delete or osgi service shutdown lifecycle).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here.. due to concurrent modification on the _brokers_
> collection
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Description:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a
service(s) removed via .cfg delete or osgi service shutdown lifecycle).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
was:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a
> service(s) removed via .cfg delete or osgi service shutdown lifecycle).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here..
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Description:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy() caused by bundle refesh
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
was:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy()
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy() caused by bundle refesh
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a service
> remove via .cfg delete).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here..
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Fix Version/s: 6.0.0
5.18.4
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.0, 5.18.4
>
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy()
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a service
> remove via .cfg delete).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here..
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Description:
Need a class instance level lock or duplicate list around the broker map when
doing a .destroy()
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
was:
Need a class instance level lock around the broker map
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need a class instance level lock or duplicate list around the broker map when
> doing a .destroy()
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a service
> remove via .cfg delete).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here..
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9376) Fix concurrent modification in ActiveMQServiceFactory
[
https://issues.apache.org/jira/browse/AMQ-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-9376:
Summary: Fix concurrent modification in ActiveMQServiceFactory (was: Fix
thread safety issue in )
> Fix concurrent modification in ActiveMQServiceFactory
> -
>
> Key: AMQ-9376
> URL: https://issues.apache.org/jira/browse/AMQ-9376
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need a class instance level lock around the broker map
> Calling .destroy() loops over a map which calls deleted.. which fails when
> there is more than one bundle and the bundle is shutdown first (not a service
> remove via .cfg delete).
> #1. OSGi calls..
> {noformat}
> synchronized public void destroy() {
> for (String broker : brokers.keySet()) {
> deleted(broker);
> }
> }
> {noformat}
> #2. Which blows up here..
> {noformat}
> @Override
> synchronized public void deleted(String pid) {
> ServiceRegistration reg = brokerRegs.remove(pid);
> if (reg != null) {
> reg.unregister();
> }
> BrokerService broker = brokers.remove(pid);
> if (broker != null) {
> stop(pid, broker);
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (AMQ-9376) Fix thread safety issue in
Matt Pavlovich created AMQ-9376:
---
Summary: Fix thread safety issue in
Key: AMQ-9376
URL: https://issues.apache.org/jira/browse/AMQ-9376
Project: ActiveMQ
Issue Type: Bug
Reporter: Matt Pavlovich
Need a class instance level lock around the broker map
Calling .destroy() loops over a map which calls deleted.. which fails when
there is more than one bundle and the bundle is shutdown first (not a service
remove via .cfg delete).
#1. OSGi calls..
{noformat}
synchronized public void destroy() {
for (String broker : brokers.keySet()) {
deleted(broker);
}
}
{noformat}
#2. Which blows up here..
{noformat}
@Override
synchronized public void deleted(String pid) {
ServiceRegistration reg = brokerRegs.remove(pid);
if (reg != null) {
reg.unregister();
}
BrokerService broker = brokers.remove(pid);
if (broker != null) {
stop(pid, broker);
}
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4483) Log.warn messages with AMQP during regular closing of AMQP clients.
Clebert Suconic created ARTEMIS-4483: Summary: Log.warn messages with AMQP during regular closing of AMQP clients. Key: ARTEMIS-4483 URL: https://issues.apache.org/jira/browse/ARTEMIS-4483 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.31.2 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.32.0 As I was fixing ARTEMIS-4476, I realized why regular closes in AMQP are throwing log.warn in the log for cleaning up sessions and even invalid connections at certain points. So, this is a complimentar task to ARTEMIS-4476. It will be part of the same git commit, but it's an unrelated issue that is going to be fixed altogether -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888358&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888358
]
ASF GitHub Bot logged work on ARTEMIS-4480:
---
Author: ASF GitHub Bot
Created on: 01/Nov/23 20:04
Start Date: 01/Nov/23 20:04
Worklog Time Spent: 10m
Work Description: AntonRoskvist commented on code in PR #4659:
URL: https://github.com/apache/activemq-artemis/pull/4659#discussion_r1379278847
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQConsumer.java:
##
@@ -517,7 +517,6 @@ public void removeRolledback(MessageReference
messageReference) {
}
public void addRolledback(MessageReference messageReference) {
- currentWindow.decrementAndGet();
Review Comment:
...yes, that is indeed the case. Verified by adding messages to rollback in
"testRedeliveredMessageNotOverflowingPrefetch" and printing deliveryCount
instead of asserting.
Issue Time Tracking
---
Worklog Id: (was: 888358)
Time Spent: 1h 20m (was: 1h 10m)
> exclusiveConsumer needs sequential operation context completion callbacks to
> ensure isolation for delivered and transacted messages
> ---
>
> Key: ARTEMIS-4480
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4480
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> in order to see order on a queue from a consumer perspective, the consumer
> must be exclusive. Any pending work for any previous consumer, delivered put
> back on the queue or pending transaction completion rollback or commit or
> close must have occurred before dispatch to a new consumer resumes.
> The removal of the consumer must wait to release the exclusive consumer flag.
> To do this it must be able to be sure that all previous completions on the
> context are done.
> This requires some additions to our operation context to enforce sequential
> completion rather than the current sequential start.
> This problem was visible with openwire which typically has a large prefetch,
> resulting in many messages in the delivering list, moved there on rollback
> from the acks list. When contention on the opernwire connection was resolved,
> the operation context nondeterminism on completion callback order became
> visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888341&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888341 ] ASF GitHub Bot logged work on ARTEMIS-4480: --- Author: ASF GitHub Bot Created on: 01/Nov/23 18:06 Start Date: 01/Nov/23 18:06 Worklog Time Spent: 10m Work Description: gtully commented on PR #4659: URL: https://github.com/apache/activemq-artemis/pull/4659#issuecomment-1789418139 I need to go back to the drawing board, the ordered executor should keep completions sequential, there must be something else at play Issue Time Tracking --- Worklog Id: (was: 888341) Time Spent: 1h 10m (was: 1h) > exclusiveConsumer needs sequential operation context completion callbacks to > ensure isolation for delivered and transacted messages > --- > > Key: ARTEMIS-4480 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, OpenWire >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > in order to see order on a queue from a consumer perspective, the consumer > must be exclusive. Any pending work for any previous consumer, delivered put > back on the queue or pending transaction completion rollback or commit or > close must have occurred before dispatch to a new consumer resumes. > The removal of the consumer must wait to release the exclusive consumer flag. > To do this it must be able to be sure that all previous completions on the > context are done. > This requires some additions to our operation context to enforce sequential > completion rather than the current sequential start. > This problem was visible with openwire which typically has a large prefetch, > resulting in many messages in the delivering list, moved there on rollback > from the acks list. When contention on the opernwire connection was resolved, > the operation context nondeterminism on completion callback order became > visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781830#comment-17781830 ] Moritz Schmitz von Hülst commented on ARTEMIS-4482: --- Hey [~jbertram] thanks for the response and help here. I tried what you have suggested and at first it seems that it helped. I set `maxDepth=3` and `maxCollectionSize=1`, update rate to `60 Seconds`. However, locally I still run into the issue that when I refresh and don't wait for the page to load yet, I am able to get into a state where the console doesn't load at all anymore. Sometimes the `Artemis` tab doesn't load (which seems to be a CSS problem though). And perhaps another question right here: Can I set these preferences somewhere in the configuration files? As IaC? > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: jolokia-prefs.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888326&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888326
]
ASF GitHub Bot logged work on ARTEMIS-4480:
---
Author: ASF GitHub Bot
Created on: 01/Nov/23 16:56
Start Date: 01/Nov/23 16:56
Worklog Time Spent: 10m
Work Description: AntonRoskvist commented on code in PR #4659:
URL: https://github.com/apache/activemq-artemis/pull/4659#discussion_r1379061456
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQConsumer.java:
##
@@ -517,7 +517,6 @@ public void removeRolledback(MessageReference
messageReference) {
}
public void addRolledback(MessageReference messageReference) {
- currentWindow.decrementAndGet();
Review Comment:
It was a while since I looked at that, but I think this change will enable
the consumer to fetch messages past the prefetchLimit. It happens when doing
redeliveries, such that it can theoretically prefetch twice as many messages as
it's supposed to.
Again, saw this quite some time back so I could be mistaken...
Issue Time Tracking
---
Worklog Id: (was: 888326)
Time Spent: 1h (was: 50m)
> exclusiveConsumer needs sequential operation context completion callbacks to
> ensure isolation for delivered and transacted messages
> ---
>
> Key: ARTEMIS-4480
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4480
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> in order to see order on a queue from a consumer perspective, the consumer
> must be exclusive. Any pending work for any previous consumer, delivered put
> back on the queue or pending transaction completion rollback or commit or
> close must have occurred before dispatch to a new consumer resumes.
> The removal of the consumer must wait to release the exclusive consumer flag.
> To do this it must be able to be sure that all previous completions on the
> context are done.
> This requires some additions to our operation context to enforce sequential
> completion rather than the current sequential start.
> This problem was visible with openwire which typically has a large prefetch,
> resulting in many messages in the delivering list, moved there on rollback
> from the acks list. When contention on the opernwire connection was resolved,
> the operation context nondeterminism on completion callback order became
> visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888312&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888312
]
ASF GitHub Bot logged work on ARTEMIS-4480:
---
Author: ASF GitHub Bot
Created on: 01/Nov/23 15:19
Start Date: 01/Nov/23 15:19
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4659:
URL: https://github.com/apache/activemq-artemis/pull/4659#discussion_r1378941324
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQConsumer.java:
##
@@ -517,7 +517,6 @@ public void removeRolledback(MessageReference
messageReference) {
}
public void addRolledback(MessageReference messageReference) {
- currentWindow.decrementAndGet();
Review Comment:
there is a prefetch rollback test in openwire that was off by one, and that
was the reason
Issue Time Tracking
---
Worklog Id: (was: 888312)
Time Spent: 50m (was: 40m)
> exclusiveConsumer needs sequential operation context completion callbacks to
> ensure isolation for delivered and transacted messages
> ---
>
> Key: ARTEMIS-4480
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4480
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> in order to see order on a queue from a consumer perspective, the consumer
> must be exclusive. Any pending work for any previous consumer, delivered put
> back on the queue or pending transaction completion rollback or commit or
> close must have occurred before dispatch to a new consumer resumes.
> The removal of the consumer must wait to release the exclusive consumer flag.
> To do this it must be able to be sure that all previous completions on the
> context are done.
> This requires some additions to our operation context to enforce sequential
> completion rather than the current sequential start.
> This problem was visible with openwire which typically has a large prefetch,
> resulting in many messages in the delivering list, moved there on rollback
> from the acks list. When contention on the opernwire connection was resolved,
> the operation context nondeterminism on completion callback order became
> visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888306&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888306
]
ASF GitHub Bot logged work on ARTEMIS-4480:
---
Author: ASF GitHub Bot
Created on: 01/Nov/23 14:51
Start Date: 01/Nov/23 14:51
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4659:
URL: https://github.com/apache/activemq-artemis/pull/4659#discussion_r1378905989
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQConsumer.java:
##
@@ -517,7 +517,6 @@ public void removeRolledback(MessageReference
messageReference) {
}
public void addRolledback(MessageReference messageReference) {
- currentWindow.decrementAndGet();
Review Comment:
why? were you having issues here?
Issue Time Tracking
---
Worklog Id: (was: 888306)
Time Spent: 40m (was: 0.5h)
> exclusiveConsumer needs sequential operation context completion callbacks to
> ensure isolation for delivered and transacted messages
> ---
>
> Key: ARTEMIS-4480
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4480
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> in order to see order on a queue from a consumer perspective, the consumer
> must be exclusive. Any pending work for any previous consumer, delivered put
> back on the queue or pending transaction completion rollback or commit or
> close must have occurred before dispatch to a new consumer resumes.
> The removal of the consumer must wait to release the exclusive consumer flag.
> To do this it must be able to be sure that all previous completions on the
> context are done.
> This requires some additions to our operation context to enforce sequential
> completion rather than the current sequential start.
> This problem was visible with openwire which typically has a large prefetch,
> resulting in many messages in the delivering list, moved there on rollback
> from the acks list. When contention on the opernwire connection was resolved,
> the operation context nondeterminism on completion callback order became
> visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888305&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888305
]
ASF GitHub Bot logged work on ARTEMIS-4480:
---
Author: ASF GitHub Bot
Created on: 01/Nov/23 14:51
Start Date: 01/Nov/23 14:51
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4659:
URL: https://github.com/apache/activemq-artemis/pull/4659#discussion_r1378905454
##
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireConnection.java:
##
@@ -1338,7 +1339,11 @@ public Response
processRemoveSubscription(RemoveSubscriptionInfo subInfo) throws
@Override
public Response processRollbackTransaction(TransactionInfo info) throws
Exception {
- Transaction tx = lookupTX(info.getTransactionId(), null, true);
+ Transaction tx = lookupTX(info.getTransactionId(), null);
+
+ if (tx == null) {
+throw new IllegalStateException("Transaction not started, " +
info.getTransactionId());
Review Comment:
I would use a logger-id from the MessageBundle.
Issue Time Tracking
---
Worklog Id: (was: 888305)
Time Spent: 0.5h (was: 20m)
> exclusiveConsumer needs sequential operation context completion callbacks to
> ensure isolation for delivered and transacted messages
> ---
>
> Key: ARTEMIS-4480
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4480
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> in order to see order on a queue from a consumer perspective, the consumer
> must be exclusive. Any pending work for any previous consumer, delivered put
> back on the queue or pending transaction completion rollback or commit or
> close must have occurred before dispatch to a new consumer resumes.
> The removal of the consumer must wait to release the exclusive consumer flag.
> To do this it must be able to be sure that all previous completions on the
> context are done.
> This requires some additions to our operation context to enforce sequential
> completion rather than the current sequential start.
> This problem was visible with openwire which typically has a large prefetch,
> resulting in many messages in the delivering list, moved there on rollback
> from the acks list. When contention on the opernwire connection was resolved,
> the operation context nondeterminism on completion callback order became
> visible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4482. - Resolution: Information Provided > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: jolokia-prefs.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4482: Attachment: (was: Screenshot 2023-11-01 at 09-25-59 Artemis Console.png) > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: jolokia-prefs.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781769#comment-17781769 ] Justin Bertram commented on ARTEMIS-4482: - This is likely due to the automatic refresh functionality used by the console by default. If there are lots of addresses and queues then the amount of information fetched from the broker and processed by the console can be quite large which can cause unresponsiveness. You can change this behavior by selecting the "Preferences" in the top right and then clicking the "Jolokia" tab. You can either disable the "Update rate" or choose a longer period. See here: !jolokia-prefs.png! You can also tune how much data is fetched using the "Max depth" and "Max collection size" options. > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: Screenshot 2023-11-01 at 09-25-59 Artemis Console.png, > jolokia-prefs.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4482: Attachment: jolokia-prefs.png > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: Screenshot 2023-11-01 at 09-25-59 Artemis Console.png, > jolokia-prefs.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4482: Attachment: Screenshot 2023-11-01 at 09-25-59 Artemis Console.png > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > Attachments: Screenshot 2023-11-01 at 09-25-59 Artemis Console.png > > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9369) ActiveMQ 6.0.0 features don't install on Karaf 4.4.x
[ https://issues.apache.org/jira/browse/AMQ-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9369. --- Resolution: Fixed > ActiveMQ 6.0.0 features don't install on Karaf 4.4.x > > > Key: AMQ-9369 > URL: https://issues.apache.org/jira/browse/AMQ-9369 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 6.0.0 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9369) ActiveMQ 6.0.0 features don't install on Karaf 4.4.x
[ https://issues.apache.org/jira/browse/AMQ-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781737#comment-17781737 ] ASF subversion and git services commented on AMQ-9369: -- Commit 5e96892424c1cd22cff638492d32ec4d217c8fdf in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=5e9689242 ] Merge pull request #1104 from jbonofre/AMQ-9369 AMQ-9369: Fix OSGi headers and Karaf features > ActiveMQ 6.0.0 features don't install on Karaf 4.4.x > > > Key: AMQ-9369 > URL: https://issues.apache.org/jira/browse/AMQ-9369 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 6.0.0 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Schmitz von Hülst updated ARTEMIS-4482: -- Environment: (was: kubernetes) > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > `kind`: > https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Schmitz von Hülst updated ARTEMIS-4482: -- Description: We somehow ran into the problem that the console for managing Artemis becomes unresponsive every now and then. I set up a guide on how I could reproduce this in a local k8s cluster using kind: [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] was: We somehow ran into the problem that the console for managing Artemis becomes unresponsive every now and then. I set up a guide on how I could reproduce this in a local k8s cluster using `kind`: https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73 > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 >Reporter: Moritz Schmitz von Hülst >Priority: Major > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > kind: > [https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9369) ActiveMQ 6.0.0 features don't install on Karaf 4.4.x
[ https://issues.apache.org/jira/browse/AMQ-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781736#comment-17781736 ] ASF subversion and git services commented on AMQ-9369: -- Commit 9c422ab34d188698d9f532080e162e4b17d60da0 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=9c422ab34 ] AMQ-9369: Fix OSGi headers and Karaf features > ActiveMQ 6.0.0 features don't install on Karaf 4.4.x > > > Key: AMQ-9369 > URL: https://issues.apache.org/jira/browse/AMQ-9369 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 6.0.0 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9369) ActiveMQ 6.0.0 features don't install on Karaf 4.4.x
[ https://issues.apache.org/jira/browse/AMQ-9369?focusedWorklogId=888285&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888285 ] ASF GitHub Bot logged work on AMQ-9369: --- Author: ASF GitHub Bot Created on: 01/Nov/23 13:39 Start Date: 01/Nov/23 13:39 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1104: URL: https://github.com/apache/activemq/pull/1104 Issue Time Tracking --- Worklog Id: (was: 888285) Time Spent: 20m (was: 10m) > ActiveMQ 6.0.0 features don't install on Karaf 4.4.x > > > Key: AMQ-9369 > URL: https://issues.apache.org/jira/browse/AMQ-9369 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 6.0.0 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Schmitz von Hülst updated ARTEMIS-4482: -- Affects Version/s: 2.31.2 2.29.0 > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX >Affects Versions: 2.29.0, 2.31.2 > Environment: kubernetes >Reporter: Moritz Schmitz von Hülst >Priority: Major > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > `kind`: > https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Schmitz von Hülst updated ARTEMIS-4482: -- Environment: kubernetes (was: Tried it locally using `kind`.) > Management console becomes unresponsive with ~300 queues/addresses > -- > > Key: ARTEMIS-4482 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMX > Environment: kubernetes >Reporter: Moritz Schmitz von Hülst >Priority: Major > > We somehow ran into the problem that the console for managing Artemis becomes > unresponsive every now and then. > I set up a guide on how I could reproduce this in a local k8s cluster using > `kind`: > https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4482) Management console becomes unresponsive with ~300 queues/addresses
Moritz Schmitz von Hülst created ARTEMIS-4482: - Summary: Management console becomes unresponsive with ~300 queues/addresses Key: ARTEMIS-4482 URL: https://issues.apache.org/jira/browse/ARTEMIS-4482 Project: ActiveMQ Artemis Issue Type: Bug Components: JMX Environment: Tried it locally using `kind`. Reporter: Moritz Schmitz von Hülst We somehow ran into the problem that the console for managing Artemis becomes unresponsive every now and then. I set up a guide on how I could reproduce this in a local k8s cluster using `kind`: https://gist.github.com/moritzschmitz-oviva/eaeec3b143e050b3da23131a3b82ce73 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9281) Upgrade to Camel 4.1.0
[ https://issues.apache.org/jira/browse/AMQ-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9281. --- Resolution: Fixed > Upgrade to Camel 4.1.0 > -- > > Key: AMQ-9281 > URL: https://issues.apache.org/jira/browse/AMQ-9281 > Project: ActiveMQ > Issue Type: Task > Components: Camel >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As we don't provide activemq-camel component, I think we should remove all > reference to Camel (maybe just keeping few itests, I will check). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9281) Upgrade to Camel 4.1.0
[ https://issues.apache.org/jira/browse/AMQ-9281?focusedWorklogId=888278&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888278 ] ASF GitHub Bot logged work on AMQ-9281: --- Author: ASF GitHub Bot Created on: 01/Nov/23 13:16 Start Date: 01/Nov/23 13:16 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1096: URL: https://github.com/apache/activemq/pull/1096 Issue Time Tracking --- Worklog Id: (was: 888278) Time Spent: 40m (was: 0.5h) > Upgrade to Camel 4.1.0 > -- > > Key: AMQ-9281 > URL: https://issues.apache.org/jira/browse/AMQ-9281 > Project: ActiveMQ > Issue Type: Task > Components: Camel >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As we don't provide activemq-camel component, I think we should remove all > reference to Camel (maybe just keeping few itests, I will check). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9281) Upgrade to Camel 4.1.0
[ https://issues.apache.org/jira/browse/AMQ-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781730#comment-17781730 ] ASF subversion and git services commented on AMQ-9281: -- Commit f44c46ca059a4a74dcb3e2b858cb9d0523272675 in activemq's branch refs/heads/main from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=f44c46ca0 ] AMQ-9281: Add Camel 4.1.0 and exclude OSGi/Karaf for now > Upgrade to Camel 4.1.0 > -- > > Key: AMQ-9281 > URL: https://issues.apache.org/jira/browse/AMQ-9281 > Project: ActiveMQ > Issue Type: Task > Components: Camel >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As we don't provide activemq-camel component, I think we should remove all > reference to Camel (maybe just keeping few itests, I will check). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9281) Upgrade to Camel 4.1.0
[ https://issues.apache.org/jira/browse/AMQ-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781731#comment-17781731 ] ASF subversion and git services commented on AMQ-9281: -- Commit 7eeaba460839ec141df67174d5254ae013295886 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=7eeaba460 ] Merge pull request #1096 from jbonofre/AMQ-9281 AMQ-9281: Add Camel 4.1.0 and exclude camel-osgi/camel-blueprint > Upgrade to Camel 4.1.0 > -- > > Key: AMQ-9281 > URL: https://issues.apache.org/jira/browse/AMQ-9281 > Project: ActiveMQ > Issue Type: Task > Components: Camel >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As we don't provide activemq-camel component, I think we should remove all > reference to Camel (maybe just keeping few itests, I will check). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4480?focusedWorklogId=888257&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-888257 ] ASF GitHub Bot logged work on ARTEMIS-4480: --- Author: ASF GitHub Bot Created on: 01/Nov/23 11:17 Start Date: 01/Nov/23 11:17 Worklog Time Spent: 10m Work Description: gtully commented on PR #4659: URL: https://github.com/apache/activemq-artemis/pull/4659#issuecomment-1788788977 sorted some xa related tests, tx in prepared state not being active, pointed to an unnecessary change. investigating some transacted mirror issues now related to closed sessions. Issue Time Tracking --- Worklog Id: (was: 888257) Time Spent: 20m (was: 10m) > exclusiveConsumer needs sequential operation context completion callbacks to > ensure isolation for delivered and transacted messages > --- > > Key: ARTEMIS-4480 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, OpenWire >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > in order to see order on a queue from a consumer perspective, the consumer > must be exclusive. Any pending work for any previous consumer, delivered put > back on the queue or pending transaction completion rollback or commit or > close must have occurred before dispatch to a new consumer resumes. > The removal of the consumer must wait to release the exclusive consumer flag. > To do this it must be able to be sure that all previous completions on the > context are done. > This requires some additions to our operation context to enforce sequential > completion rather than the current sequential start. > This problem was visible with openwire which typically has a large prefetch, > resulting in many messages in the delivering list, moved there on rollback > from the acks list. When contention on the opernwire connection was resolved, > the operation context nondeterminism on completion callback order became > visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
