[jira] [Work logged] (ARTEMIS-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?focusedWorklogId=924000=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-924000
]
ASF GitHub Bot logged work on ARTEMIS-4831:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:27
Start Date: 21/Jun/24 14:27
Worklog Time Spent: 10m
Work Description: gemmellr opened a new pull request, #4989:
URL: https://github.com/apache/activemq-artemis/pull/4989
Always use surefure default behaviour by default: fail module build when a
test fails.
Anyone wanting to ignore failures so as to run all modules, can use the
standard surefire prop to request that, e.g:
mvn test -Dmaven.test.failure.ignore
Issue Time Tracking
---
Worklog Id: (was: 924000)
Remaining Estimate: 0h
Time Spent: 10m
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?focusedWorklogId=924003=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-924003
]
ASF GitHub Bot logged work on ARTEMIS-4831:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:27
Start Date: 21/Jun/24 14:27
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4989:
URL: https://github.com/apache/activemq-artemis/pull/4989#discussion_r1647531286
##
pom.xml:
##
@@ -861,9 +858,7 @@
1
true
- ${testFailureIgnore}
alphabetical
-
${maven.test.redirectTestOutputToFile}
Review Comment:
Not strictly related, but since both are using the standard surefire
properties it is superfluous, so when removing the other configuration element
I took this out too.
##
pom.xml:
##
@@ -861,9 +858,7 @@
1
true
- ${testFailureIgnore}
alphabetical
-
${maven.test.redirectTestOutputToFile}
Review Comment:
Not strictly related other than being the same type of cleanup; since both
are using the standard surefire properties they are superfluous, so when
removing the other configuration element I took this out too.
Issue Time Tracking
---
Worklog Id: (was: 924003)
Time Spent: 20m (was: 10m)
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923986=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923986
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:24
Start Date: 21/Jun/24 14:24
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972
Issue Time Tracking
---
Worklog Id: (was: 923986)
Time Spent: 4h 10m (was: 4h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923985=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923985
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:24
Start Date: 21/Jun/24 14:24
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2177354426
I'm actually going to merge this now...
Thanks for this.
Issue Time Tracking
---
Worklog Id: (was: 923985)
Time Spent: 4h (was: 3h 50m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923976=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923976
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:22
Start Date: 21/Jun/24 14:22
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1645202926
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +104,11 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.compute(binding.getAddress(), (key, value) -> {
+ Collection bindingList = value == null ? new ArrayList<>() :
value;
+ bindingList.add(binding);
Review Comment:
Yeah.. I did some testing.. I thought the compute would do a loop retry only
(I read the wrong code).
I added some testing.. and I changed your code with adding sleeps and
everything worked.. I could see the wait to lock threads.
If you could rebase against main now that I added a test to validate this?
also, you can verify check style by doing this:
mvn -Pdev install -DskipTests=true -T2
Issue Time Tracking
---
Worklog Id: (was: 923976)
Time Spent: 3h 50m (was: 3h 40m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923970=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923970
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:22
Start Date: 21/Jun/24 14:22
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2177236106
I think this can be merged.. I will leave it open for a 1 or 2 days if
anyone else wants to give some feedback, but this is +1 from me.
Issue Time Tracking
---
Worklog Id: (was: 923970)
Time Spent: 3h 40m (was: 3.5h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923963=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923963
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 21:36
Start Date: 18/Jun/24 21:36
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2177070523
> There are several checkstyle violations that needs addressed here as well.
Sorry, Checkstyle not working locally for me. Think I have fixed the issues
now.
Issue Time Tracking
---
Worklog Id: (was: 923963)
Time Spent: 3.5h (was: 3h 20m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923960=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923960
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 21:08
Start Date: 18/Jun/24 21:08
Worklog Time Spent: 10m
Work Description: tabish121 commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2176977615
There are several checkstyle violations that needs addressed here as well.
Issue Time Tracking
---
Worklog Id: (was: 923960)
Time Spent: 3h 20m (was: 3h 10m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923950=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923950
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 19:38
Start Date: 18/Jun/24 19:38
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1644955884
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +104,11 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.compute(binding.getAddress(), (key, value) -> {
+ Collection bindingList = value == null ? new ArrayList<>() :
value;
+ bindingList.add(binding);
Review Comment:
The `directBindingMap` is a `ConcurrentHashMap` so it will guarantee thread
safety on the `compute` by locking the node.
https://stackoverflow.com/a/59601136
Also, this should be tested already via
`WildcardAddressManagerUnitTest#testConcurrentCalls`.
Issue Time Tracking
---
Worklog Id: (was: 923950)
Time Spent: 3h 10m (was: 3h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923941=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923941
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 17:19
Start Date: 18/Jun/24 17:19
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1644813299
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +104,11 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.compute(binding.getAddress(), (key, value) -> {
+ Collection bindingList = value == null ? new ArrayList<>() :
value;
+ bindingList.add(binding);
Review Comment:
say you call this from different threads...
perhaps we should add a test having mulitple threads on this call here, and
make sure the outcome is as expected.
Issue Time Tracking
---
Worklog Id: (was: 923941)
Time Spent: 3h (was: 2h 50m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923940=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923940
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 17:18
Start Date: 18/Jun/24 17:18
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1644812334
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +104,11 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.compute(binding.getAddress(), (key, value) -> {
+ Collection bindingList = value == null ? new ArrayList<>() :
value;
+ bindingList.add(binding);
Review Comment:
Maybe I'm being naive... but as far as I remember.. the ArrayList itself is
not supposed to be used from multiple threads.
The compute will do a replay, but you could still call the compute from
multiple threads.
I feel like you should have:
```
synchronized(bindingList) {
bindingsList.add(binding);
}
```
Or another data structure to be used here.
similarly on the remove the queue, it should use a synchronized or use a
concurrent equivalent.
Issue Time Tracking
---
Worklog Id: (was: 923940)
Time Spent: 2h 50m (was: 2h 40m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?focusedWorklogId=923924=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923924
]
ASF GitHub Bot logged work on ARTEMIS-4819:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 15:19
Start Date: 18/Jun/24 15:19
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4980:
URL:
https://github.com/apache/activemq-artemis/pull/4980#issuecomment-217636
I just had an issue with ./artemis queue stat where some users complained to
me about parsing the output. so I added --json
if json is no good for scripting, we could add some other format output for
things like that.
We should do it in a way we are consistent throughout the CLI. doing it now
in one way here, and on a different way on queue stat makes it confusing.
Issue Time Tracking
---
Worklog Id: (was: 923924)
Time Spent: 50m (was: 40m)
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?focusedWorklogId=923913=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923913
]
ASF GitHub Bot logged work on ARTEMIS-4819:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 14:40
Start Date: 18/Jun/24 14:40
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4980:
URL:
https://github.com/apache/activemq-artemis/pull/4980#issuecomment-2176275423
> I don't really think that it is in a spirit of Bash shell scripting.
I'm not heavy into Bash shell scripting so I may not be the best judge of
it's "spirit," but the fact that the [`jq`](https://jqlang.github.io/jq/)
command exists and appears to be popular indicates that lots of folks are
dealing with JSON from the shell.
> It also assumes that jq or any other JSON tool is available, which is not
necessary true.
That's true, but given the popularity of JSON I think that's a relatively
safe assumption.
> If you are worried that proposed output is not clear or pretty, another
way to go could be to add additional flag to output the list without
decorations.
My chief concern is that we don't needlessly complicate something that was
designed to be very simple. If you want to treat the output of the CLI as an
API (i.e. to be used in scripts and other commands) then you can't simply
change it between minor versions because you'll break anybody who is already
relying on the existing output format. If you want to eventually replace the
existing output you must first deprecate it and provide a new flag or command.
Then when a new major version is released we can remove the deprecated item.
You can see how a small change like this can grow into something much larger.
Of course, that's not to mention the subjective evaluation of what is _clear_
or _pretty_.
Ultimately I think we should encourage folks to use tools the way they were
designed to be used. In short, use the management API if you need an API and
use the CLI for simple, human tasks. I recently [clarified the
documentation](https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/using-cli.adoc#command-line-interface)
to this end.
Issue Time Tracking
---
Worklog Id: (was: 923913)
Time Spent: 40m (was: 0.5h)
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?focusedWorklogId=923882=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923882 ] ASF GitHub Bot logged work on ARTEMIS-4818: --- Author: ASF GitHub Bot Created on: 18/Jun/24 12:05 Start Date: 18/Jun/24 12:05 Worklog Time Spent: 10m Work Description: gemmellr merged PR #4983: URL: https://github.com/apache/activemq-artemis/pull/4983 Issue Time Tracking --- Worklog Id: (was: 923882) Time Spent: 50m (was: 40m) > Improve support for multiple broker plugins from broker properties > -- > > Key: ARTEMIS-4818 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4818 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The broker support loading multiple broker plugins from the broker properties > only if they expose a getter/setter for the property name. Could you support > loading multiple broker plugins without a getter/setter for the property name? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?focusedWorklogId=923879=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923879 ] ASF GitHub Bot logged work on ARTEMIS-4818: --- Author: ASF GitHub Bot Created on: 18/Jun/24 11:26 Start Date: 18/Jun/24 11:26 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request, #4983: URL: https://github.com/apache/activemq-artemis/pull/4983 (no comment) Issue Time Tracking --- Worklog Id: (was: 923879) Time Spent: 40m (was: 0.5h) > Improve support for multiple broker plugins from broker properties > -- > > Key: ARTEMIS-4818 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4818 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > The broker support loading multiple broker plugins from the broker properties > only if they expose a getter/setter for the property name. Could you support > loading multiple broker plugins without a getter/setter for the property name? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[
https://issues.apache.org/jira/browse/ARTEMIS-4818?focusedWorklogId=923860=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923860
]
ASF GitHub Bot logged work on ARTEMIS-4818:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 10:27
Start Date: 18/Jun/24 10:27
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4979:
URL: https://github.com/apache/activemq-artemis/pull/4979#discussion_r1644220864
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImpl.java:
##
@@ -3489,10 +3498,19 @@ private Object trackCollectionOrMap(String name, Object
resolved, Object bean) {
private Object findByNameProperty(String key, Collection collection)
throws InvocationTargetException, IllegalAccessException, NoSuchMethodException
{
// locate on name property, may be a SimpleString
- for (Object candidate : collection) {
-Object candidateName = getProperty(candidate, "name");
-if (candidateName != null && key.equals(candidateName.toString()))
{
- return candidate;
+ if (isClassProperty(key)) {
Review Comment:
The comment on the line above this should either be adjusted, or move down
toward the code it applied to originally.
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImpl.java:
##
@@ -958,6 +958,15 @@ public T convert(Class type, Object value) {
updateApplyStatus(propsId, errors);
}
+ private static boolean isClassProperty(String property) {
+ return property.endsWith(PROPERTY_CLASS_SUFFIX);
+ }
+
+ private static String extractPropertyClassName(String property) {
+ int propertyClassSuffixIndex = property.indexOf(PROPERTY_CLASS_SUFFIX);
+ return property.substring(0, propertyClassSuffixIndex);
+ }
Review Comment:
These two are a bit inconsistent, in that the first one only checks for
_endsWith_, but the second extracts only up to the _first_ instance found,
which could be different. Would be better if they both operated on the end
basis for consistency (also saves looking for the location index of a value you
can already calculate).
Issue Time Tracking
---
Worklog Id: (was: 923860)
Time Spent: 0.5h (was: 20m)
> Improve support for multiple broker plugins from broker properties
> --
>
> Key: ARTEMIS-4818
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4818
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The broker support loading multiple broker plugins from the broker properties
> only if they expose a getter/setter for the property name. Could you support
> loading multiple broker plugins without a getter/setter for the property name?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?focusedWorklogId=923857=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923857 ] ASF GitHub Bot logged work on ARTEMIS-4818: --- Author: ASF GitHub Bot Created on: 18/Jun/24 10:17 Start Date: 18/Jun/24 10:17 Worklog Time Spent: 10m Work Description: gtully merged PR #4979: URL: https://github.com/apache/activemq-artemis/pull/4979 Issue Time Tracking --- Worklog Id: (was: 923857) Time Spent: 20m (was: 10m) > Improve support for multiple broker plugins from broker properties > -- > > Key: ARTEMIS-4818 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4818 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The broker support loading multiple broker plugins from the broker properties > only if they expose a getter/setter for the property name. Could you support > loading multiple broker plugins without a getter/setter for the property name? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?focusedWorklogId=923841=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923841
]
ASF GitHub Bot logged work on ARTEMIS-4819:
---
Author: ASF GitHub Bot
Created on: 18/Jun/24 08:06
Start Date: 18/Jun/24 08:06
Worklog Time Spent: 10m
Work Description: ViliusS commented on PR #4980:
URL:
https://github.com/apache/activemq-artemis/pull/4980#issuecomment-2175466690
While I agree that JSON could be suitable for programming languages which
natively support it, I don't really think that it is in a spirit of Bash shell
scripting. Parsing JSON would involve much more complicated steps, first
parsing the output, then somehow storing parsed data in a temporary variable,
and only then doing needed actions on users. It also assumes that jq or any
other JSON tool is available, which is not necessary true.
Linux already has all the tool it needs for such trivial task and all of
them use spaces as parsing markers, does parsing automatically, effectively
directly from SDIN.
Issue Time Tracking
---
Worklog Id: (was: 923841)
Time Spent: 0.5h (was: 20m)
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?focusedWorklogId=923789=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923789
]
ASF GitHub Bot logged work on ARTEMIS-4819:
---
Author: ASF GitHub Bot
Created on: 17/Jun/24 19:22
Start Date: 17/Jun/24 19:22
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4980:
URL:
https://github.com/apache/activemq-artemis/pull/4980#issuecomment-2174250407
I'm not in favor of this change. If you want output that's formatted clearly
and in a way that can be parsed by scripts then I recommend the [management
API](https://activemq.apache.org/components/artemis/documentation/latest/management.html#management).
In this can you could invoke the [`listUser` operation on
`ActiveMQServerControl`](https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.html#listUser(java.lang.String)),
e.g. this command:
```
curl -s -H "Origin: http://localhost; -u myUser:myPass --header
"Content-type: application/json" --request POST --data '{"operation":
"listUser", "mbean": "org.apache.activemq.artemis:broker=\"0.0.0.0\"", "type":
"exec", "arguments": [""] }' http://localhost:8161/console/jolokia | jq '.value
| fromjson'
```
Might provide output like this:
```json
[
{
"username": "myUser1",
"roles": [
"myRole1"
]
},
{
"username": "myUser2",
"roles": [
"myRole2",
"myRole3"
]
}
]
```
Issue Time Tracking
---
Worklog Id: (was: 923789)
Time Spent: 20m (was: 10m)
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4820) AMQP TTL message property being treated as int instead of uint
[ https://issues.apache.org/jira/browse/ARTEMIS-4820?focusedWorklogId=923773=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923773 ] ASF GitHub Bot logged work on ARTEMIS-4820: --- Author: ASF GitHub Bot Created on: 17/Jun/24 18:32 Start Date: 17/Jun/24 18:32 Worklog Time Spent: 10m Work Description: jbertram merged PR #4982: URL: https://github.com/apache/activemq-artemis/pull/4982 Issue Time Tracking --- Worklog Id: (was: 923773) Time Spent: 20m (was: 10m) > AMQP TTL message property being treated as int instead of uint > -- > > Key: ARTEMIS-4820 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4820 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When setting message expiration from AMQP header TTL the value should be > treated as an unsigned integer but is instead being read as a signed integer. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4820) AMQP TTL message property being treated as int instead of uint
[ https://issues.apache.org/jira/browse/ARTEMIS-4820?focusedWorklogId=923763=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923763 ] ASF GitHub Bot logged work on ARTEMIS-4820: --- Author: ASF GitHub Bot Created on: 17/Jun/24 17:55 Start Date: 17/Jun/24 17:55 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4982: URL: https://github.com/apache/activemq-artemis/pull/4982 When setting expiration on the AMQPMessage the AMQP header TTL value should be read as an unsigned integer and as such should use the longValue API of UnsignedInteger to get the right value to set expiration. Issue Time Tracking --- Worklog Id: (was: 923763) Remaining Estimate: 0h Time Spent: 10m > AMQP TTL message property being treated as int instead of uint > -- > > Key: ARTEMIS-4820 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4820 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When setting message expiration from AMQP header TTL the value should be > treated as an unsigned integer but is instead being read as a signed integer. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?focusedWorklogId=923593=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923593
]
ASF GitHub Bot logged work on ARTEMIS-4819:
---
Author: ASF GitHub Bot
Created on: 15/Jun/24 07:17
Start Date: 15/Jun/24 07:17
Worklog Time Spent: 10m
Work Description: ViliusS opened a new pull request, #4980:
URL: https://github.com/apache/activemq-artemis/pull/4980
Previously it was not so easy to parse `artemis user list` output. If one
would want to do something in a bash script with every user he had to do
something like this:
```
while read -r user; do something with `echo $user | sed
's/^"\(.*\)".*/\1/'`; done < ./artemis user list --url tcp://localhost:61616
--user admin --password pass
```
This patch splits user and roles with a space and removes quotes around the
user. So now one could just do:
```
while read -r user roles; do something with $user; done < ./artemis user
list --url tcp://localhost:61616 --user admin --password pass
```
Issue Time Tracking
---
Worklog Id: (was: 923593)
Remaining Estimate: 0h
Time Spent: 10m
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[
https://issues.apache.org/jira/browse/ARTEMIS-4818?focusedWorklogId=923462=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923462
]
ASF GitHub Bot logged work on ARTEMIS-4818:
---
Author: ASF GitHub Bot
Created on: 14/Jun/24 08:32
Start Date: 14/Jun/24 08:32
Worklog Time Spent: 10m
Work Description: brusdev opened a new pull request, #4979:
URL: https://github.com/apache/activemq-artemis/pull/4979
…properties
Issue Time Tracking
---
Worklog Id: (was: 923462)
Remaining Estimate: 0h
Time Spent: 10m
> Improve support for multiple broker plugins from broker properties
> --
>
> Key: ARTEMIS-4818
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4818
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The broker support loading multiple broker plugins from the broker properties
> only if they have a different class and expose a getter/setter for the
> property name. Could you improve the broker property syntax to define the
> class instance name in the key optionally? In this way, users could add
> multiple instances of the same broker plugin even if it has no getter/setter
> for the property name, i.e.
> {code}
> brokerPlugins."org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin#my-instance-0.class".init=LOG_ALL_EVENTS=false
> brokerPlugins."org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin#my-instance-1.class".init=LOG_ALL_EVENTS=true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923431=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923431
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 14/Jun/24 05:35
Start Date: 14/Jun/24 05:35
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1639286235
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +102,8 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.computeIfAbsent(binding.getAddress(), (unused) -> new
ArrayList<>())
+ .add(binding);
Review Comment:
Now using an `ArrayList` given that the modifications are happening in a
(synchronized) `compute` block.
Issue Time Tracking
---
Worklog Id: (was: 923431)
Time Spent: 2h 40m (was: 2.5h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923430=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923430
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 14/Jun/24 05:35
Start Date: 14/Jun/24 05:35
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1639285762
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -116,7 +121,15 @@ public Binding removeBinding(final SimpleString
uniqueName, Transaction tx) thro
return null;
}
- removeBindingInternal(binding.getA().getAddress(), uniqueName);
+ SimpleString address = binding.getA().getAddress();
+ removeBindingInternal(address, uniqueName);
+ Collection directBindings = directBindingMap.get(address);
+ if (directBindings != null) {
+ directBindings.remove(binding.getA());
+ if (directBindings.isEmpty()) {
Review Comment:
I have now used `compute` which should take advantage of the striped locking
nature of the map, and should remove the race condition mentioned.
Issue Time Tracking
---
Worklog Id: (was: 923430)
Time Spent: 2.5h (was: 2h 20m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923398=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923398
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 23:11
Start Date: 13/Jun/24 23:11
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1639034848
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +102,8 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.computeIfAbsent(binding.getAddress(), (unused) -> new
ArrayList<>())
+ .add(binding);
Review Comment:
Using a copy on write structure would seem to be adding a significant amount
of GC overhead as each new binding will copy the array and toss out the old
instance.
Issue Time Tracking
---
Worklog Id: (was: 923398)
Time Spent: 2h 20m (was: 2h 10m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923397=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923397
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 22:49
Start Date: 13/Jun/24 22:49
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1639023553
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -116,7 +121,15 @@ public Binding removeBinding(final SimpleString
uniqueName, Transaction tx) thro
return null;
}
- removeBindingInternal(binding.getA().getAddress(), uniqueName);
+ SimpleString address = binding.getA().getAddress();
+ removeBindingInternal(address, uniqueName);
+ Collection directBindings = directBindingMap.get(address);
+ if (directBindings != null) {
+ directBindings.remove(binding.getA());
+ if (directBindings.isEmpty()) {
Review Comment:
Should we perhaps put this in a `ConcurrentHashMap#compute` lambda instead?
Issue Time Tracking
---
Worklog Id: (was: 923397)
Time Spent: 2h 10m (was: 2h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923396=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923396
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 22:44
Start Date: 13/Jun/24 22:44
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1639020568
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -116,7 +121,15 @@ public Binding removeBinding(final SimpleString
uniqueName, Transaction tx) thro
return null;
}
- removeBindingInternal(binding.getA().getAddress(), uniqueName);
+ SimpleString address = binding.getA().getAddress();
+ removeBindingInternal(address, uniqueName);
+ Collection directBindings = directBindingMap.get(address);
+ if (directBindings != null) {
+ directBindings.remove(binding.getA());
+ if (directBindings.isEmpty()) {
Review Comment:
Isn't there a race condition here in that the directBindings collection
might report empty here but a new binding could be added between this check and
the next call to remove the bindings entry from the Map meaning that the
tracked state is now inconsistent with reality?
Issue Time Tracking
---
Worklog Id: (was: 923396)
Time Spent: 2h (was: 1h 50m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
[ https://issues.apache.org/jira/browse/ARTEMIS-4817?focusedWorklogId=923392=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923392 ] ASF GitHub Bot logged work on ARTEMIS-4817: --- Author: ASF GitHub Bot Created on: 13/Jun/24 22:35 Start Date: 13/Jun/24 22:35 Worklog Time Spent: 10m Work Description: tabish121 merged PR #4977: URL: https://github.com/apache/activemq-artemis/pull/4977 Issue Time Tracking --- Worklog Id: (was: 923392) Time Spent: 20m (was: 10m) > AMQP Federation address policy doesn't allow credit configuration to override > parent settings > - > > Key: ARTEMIS-4817 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4817 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0, 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When processing address matches the federation address policy manager doesn't > check against the address policy for a receiver credits value but instead > looks at the parent level settings which means if the global value is set to > zero and the address policy has an override this is missed and it won't > federate an address. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-2892) Replication stopped working after many failovers
[
https://issues.apache.org/jira/browse/ARTEMIS-2892?focusedWorklogId=923387=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923387
]
ASF GitHub Bot logged work on ARTEMIS-2892:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 21:48
Start Date: 13/Jun/24 21:48
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4978:
URL: https://github.com/apache/activemq-artemis/pull/4978
Issue Time Tracking
---
Worklog Id: (was: 923387)
Time Spent: 20m (was: 10m)
> Replication stopped working after many failovers
>
>
> Key: ARTEMIS-2892
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2892
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0
>Reporter: Chris Oman
>Priority: Major
> Labels: replication
> Attachments: artemis-1017.log, artemis-1019.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have 2 servers that we have been testing the failover capabilities with.
> We have encountered a situation where replication has completely stopped, but
> the master is working properly otherwise.
> When the backup attempts to connect, the master has this in its logs.
> {code:java}
> 2020-09-01 11:23:31,177 WARN [org.apache.activemq.artemis.core.server]
> AMQ222013: Error when trying to start replication:
> ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=AMQ229006:
> journals are not JournalImpl. You can''t set a replicator!]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:628)
> [artemis-server-2.11.0.jar:2.11.0]
> at
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:178)
> [artemis-server-2.11.0.jar:2.11.0]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_201]
> {code}
> How can this happen? Up until this point, replication was working properly
> through all of the failovers (10+).
> I have attached the logs files from both systems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923376=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923376
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 18:55
Start Date: 13/Jun/24 18:55
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1638740605
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +102,8 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.computeIfAbsent(binding.getAddress(), (unused) -> new
ArrayList<>())
+ .add(binding);
Review Comment:
Good point, definitely should be thread-safe. Changed to a COW ArrayList.
Issue Time Tracking
---
Worklog Id: (was: 923376)
Time Spent: 1h 50m (was: 1h 40m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-2892) Replication stopped working after many failovers
[
https://issues.apache.org/jira/browse/ARTEMIS-2892?focusedWorklogId=923384=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923384
]
ASF GitHub Bot logged work on ARTEMIS-2892:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 20:44
Start Date: 13/Jun/24 20:44
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request, #4978:
URL: https://github.com/apache/activemq-artemis/pull/4978
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 923384)
Remaining Estimate: 0h
Time Spent: 10m
> Replication stopped working after many failovers
>
>
> Key: ARTEMIS-2892
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2892
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.11.0
>Reporter: Chris Oman
>Priority: Major
> Labels: replication
> Attachments: artemis-1017.log, artemis-1019.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have 2 servers that we have been testing the failover capabilities with.
> We have encountered a situation where replication has completely stopped, but
> the master is working properly otherwise.
> When the backup attempts to connect, the master has this in its logs.
> {code:java}
> 2020-09-01 11:23:31,177 WARN [org.apache.activemq.artemis.core.server]
> AMQ222013: Error when trying to start replication:
> ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=AMQ229006:
> journals are not JournalImpl. You can''t set a replicator!]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:628)
> [artemis-server-2.11.0.jar:2.11.0]
> at
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:178)
> [artemis-server-2.11.0.jar:2.11.0]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_201]
> {code}
> How can this happen? Up until this point, replication was working properly
> through all of the failovers (10+).
> I have attached the logs files from both systems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9455) DestinationPolicy to support MessageInterceptorStrategy
[ https://issues.apache.org/jira/browse/AMQ-9455?focusedWorklogId=923371=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923371 ] ASF GitHub Bot logged work on AMQ-9455: --- Author: ASF GitHub Bot Created on: 13/Jun/24 17:52 Start Date: 13/Jun/24 17:52 Worklog Time Spent: 10m Work Description: mattrpav merged PR #1182: URL: https://github.com/apache/activemq/pull/1182 Issue Time Tracking --- Worklog Id: (was: 923371) Time Spent: 50m (was: 40m) > DestinationPolicy to support MessageInterceptorStrategy > --- > > Key: AMQ-9455 > URL: https://issues.apache.org/jira/browse/AMQ-9455 > Project: ActiveMQ Classic > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Fix For: 6.2.0 > > Time Spent: 50m > Remaining Estimate: 0h > > A configurable list of message policy entries that will all for message > enrichment and enforcement of message content policies. > This feature would serve to replace broker-wide plugins: > ForcePersistencyModeBrokerPlugin > TimeStampingBrokerPLugin > UserIDBroker -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923355=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923355
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 15:59
Start Date: 13/Jun/24 15:59
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1638460217
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +102,8 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.computeIfAbsent(binding.getAddress(), (unused) -> new
ArrayList<>())
+ .add(binding);
Review Comment:
you are using ConcurrentHashMap on the directBindingsMap, however you're
using a non Concurrent list on the value (new ArrayList)
I'm wondering if we shouldn't use something more protective in multi-thread
here.
I understand it's unlikely the broker to remove or add a queue on the same
address from multiple threads.. but it's not impossible. (say an application
with a MultiCast address and applications creating and deleting subscriptions
from multiple places).
it would be a rare race, but difficult to track if it ever happened.
Shouldn't we use something more protective here.. perhaps CopyOnWrite or
anything else?
Issue Time Tracking
---
Worklog Id: (was: 923355)
Time Spent: 1h 40m (was: 1.5h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
[ https://issues.apache.org/jira/browse/ARTEMIS-4817?focusedWorklogId=923356=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923356 ] ASF GitHub Bot logged work on ARTEMIS-4817: --- Author: ASF GitHub Bot Created on: 13/Jun/24 16:01 Start Date: 13/Jun/24 16:01 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4977: URL: https://github.com/apache/activemq-artemis/pull/4977 When checking if address federation can be done the manager needs to look at the policy level settings before looking at federation or connector level settings for amqp credits. Issue Time Tracking --- Worklog Id: (was: 923356) Remaining Estimate: 0h Time Spent: 10m > AMQP Federation address policy doesn't allow credit configuration to override > parent settings > - > > Key: ARTEMIS-4817 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4817 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0, 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When processing address matches the federation address policy manager doesn't > check against the address policy for a receiver credits value but instead > looks at the parent level settings which means if the global value is set to > zero and the address policy has an override this is missed and it won't > federate an address. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923354=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923354
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 15:58
Start Date: 13/Jun/24 15:58
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1638460217
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +102,8 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.computeIfAbsent(binding.getAddress(), (unused) -> new
ArrayList<>())
+ .add(binding);
Review Comment:
you are using ConcurrentHashMap on the directBindingsMap, however you're
using a non Concurrent list on directBindingsMap.
I'm wondering if we shouldn't use something more protective in multi-thread
here.
I understand it's unlikely the broker to remove or add a queue on the same
address from multiple threads.. but it's not impossible. (say an application
with a MultiCast address and applications creating and deleting subscriptions
from multiple places).
it would be a rare race, but difficult to track if it ever happened.
Shouldn't we use something more protective here.. perhaps CopyOnWrite or
anything else?
Issue Time Tracking
---
Worklog Id: (was: 923354)
Time Spent: 1.5h (was: 1h 20m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4816) Docker image echo's admin credentials during startup
[ https://issues.apache.org/jira/browse/ARTEMIS-4816?focusedWorklogId=923353=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923353 ] ASF GitHub Bot logged work on ARTEMIS-4816: --- Author: ASF GitHub Bot Created on: 13/Jun/24 15:40 Start Date: 13/Jun/24 15:40 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4976: URL: https://github.com/apache/activemq-artemis/pull/4976 Issue Time Tracking --- Worklog Id: (was: 923353) Time Spent: 20m (was: 10m) > Docker image echo's admin credentials during startup > > > Key: ARTEMIS-4816 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4816 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Image >Reporter: StandByStormMetaM >Priority: Blocker > Time Spent: 20m > Remaining Estimate: 0h > > The artemis-docker/docker-run.sh contains an echo of the startup arguments > containing the admin credentials. > For troubleshooting the output of our pods are fed to kibana. People > analyzing these logs should not have the ability to see these credentials > hence the proposal to remove this echo. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4816) Docker image echo's admin credentials during startup
[ https://issues.apache.org/jira/browse/ARTEMIS-4816?focusedWorklogId=923351=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923351 ] ASF GitHub Bot logged work on ARTEMIS-4816: --- Author: ASF GitHub Bot Created on: 13/Jun/24 15:09 Start Date: 13/Jun/24 15:09 Worklog Time Spent: 10m Work Description: StandByStormMetaMaster opened a new pull request, #4976: URL: https://github.com/apache/activemq-artemis/pull/4976 The artemis-docker/docker-run.sh contains an echo of the startup arguments containing the admin credentials. For troubleshooting the output of our pods are fed to kibana. People analyzing these logs should not have the ability to see these credentials hence the proposal to remove this echo. Issue Time Tracking --- Worklog Id: (was: 923351) Remaining Estimate: 0h Time Spent: 10m > Docker image echo's admin credentials during startup > > > Key: ARTEMIS-4816 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4816 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Image >Reporter: StandByStormMetaM >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > The artemis-docker/docker-run.sh contains an echo of the startup arguments > containing the admin credentials. > For troubleshooting the output of our pods are fed to kibana. People > analyzing these logs should not have the ability to see these credentials > hence the proposal to remove this echo. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=923259=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923259
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 13/Jun/24 08:53
Start Date: 13/Jun/24 08:53
Worklog Time Spent: 10m
Work Description: iiliev2 commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2165039460
Fixed the checkstyle issues.
Issue Time Tracking
---
Worklog Id: (was: 923259)
Time Spent: 1.5h (was: 1h 20m)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4667) JMX Recovery operation triggers ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-4667?focusedWorklogId=923184=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923184
]
ASF GitHub Bot logged work on ARTEMIS-4667:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 22:42
Start Date: 12/Jun/24 22:42
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request, #4974:
URL: https://github.com/apache/activemq-artemis/pull/4974
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 923184)
Time Spent: 0.5h (was: 20m)
> JMX Recovery operation triggers ClassCastException
> --
>
> Key: ARTEMIS-4667
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4667
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.30.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.36.0
>
> Attachments: ReplayWithReplicationTest.java,
> msg-replay-classcastexception.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> *Description:*
> Impossibility to replay messages from retention folders due to a
> ClassCastException.
> It happens when replication ha-policy is configured and after the live role
> switch back from the backup node to the primary node:
>
> {code:java}
> java.lang.ClassCastException : class
> org.apache.activemq.artemis.core.replication.ReplicatedJournal cannot be cast
> to class org.apache.activemq.artemis.core.journal.impl.JournalImpl
> (org.apache.activemq.artemis.core.replication.ReplicatedJournal and
> org.apache.activemq.artemis.core.journal.impl.JournalImpl are in unnamed
> module of loader java.net.URLClassLoader @73d16e93){code}
>
> See attached screenshot of the Artemis console for additional details.
>
> *Configuration details:*
> * Cluster of Artemis primary/backup groups and with replication ha-policy
> (ZK)
>
> *Reproduction scenario:*
> With a brand new primary/backup group with replica :
> * Start primary and backup nodes
> * The JMX replay command works well on primary
> * Stop the primary node, backup becomes live
> * Restart the primary, it becomes live again (failback is enabled)
> * At this step, the reuse of the replay command on the primary trigger the
> ClassCastException
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4667) JMX Recovery operation triggers ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-4667?focusedWorklogId=923182=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923182
]
ASF GitHub Bot logged work on ARTEMIS-4667:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 21:57
Start Date: 12/Jun/24 21:57
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4973:
URL: https://github.com/apache/activemq-artemis/pull/4973
Issue Time Tracking
---
Worklog Id: (was: 923182)
Time Spent: 20m (was: 10m)
> JMX Recovery operation triggers ClassCastException
> --
>
> Key: ARTEMIS-4667
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4667
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.30.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.36.0
>
> Attachments: ReplayWithReplicationTest.java,
> msg-replay-classcastexception.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Description:*
> Impossibility to replay messages from retention folders due to a
> ClassCastException.
> It happens when replication ha-policy is configured and after the live role
> switch back from the backup node to the primary node:
>
> {code:java}
> java.lang.ClassCastException : class
> org.apache.activemq.artemis.core.replication.ReplicatedJournal cannot be cast
> to class org.apache.activemq.artemis.core.journal.impl.JournalImpl
> (org.apache.activemq.artemis.core.replication.ReplicatedJournal and
> org.apache.activemq.artemis.core.journal.impl.JournalImpl are in unnamed
> module of loader java.net.URLClassLoader @73d16e93){code}
>
> See attached screenshot of the Artemis console for additional details.
>
> *Configuration details:*
> * Cluster of Artemis primary/backup groups and with replication ha-policy
> (ZK)
>
> *Reproduction scenario:*
> With a brand new primary/backup group with replica :
> * Start primary and backup nodes
> * The JMX replay command works well on primary
> * Stop the primary node, backup becomes live
> * Restart the primary, it becomes live again (failback is enabled)
> * At this step, the reuse of the replay command on the primary trigger the
> ClassCastException
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4667) JMX Recovery operation triggers ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-4667?focusedWorklogId=923180=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923180
]
ASF GitHub Bot logged work on ARTEMIS-4667:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 21:22
Start Date: 12/Jun/24 21:22
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request, #4973:
URL: https://github.com/apache/activemq-artemis/pull/4973
co-authored: Jean-Pascal Briquet provided the testcase
Issue Time Tracking
---
Worklog Id: (was: 923180)
Remaining Estimate: 0h
Time Spent: 10m
> JMX Recovery operation triggers ClassCastException
> --
>
> Key: ARTEMIS-4667
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4667
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.30.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.36.0
>
> Attachments: ReplayWithReplicationTest.java,
> msg-replay-classcastexception.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Description:*
> Impossibility to replay messages from retention folders due to a
> ClassCastException.
> It happens when replication ha-policy is configured and after the live role
> switch back from the backup node to the primary node:
>
> {code:java}
> java.lang.ClassCastException : class
> org.apache.activemq.artemis.core.replication.ReplicatedJournal cannot be cast
> to class org.apache.activemq.artemis.core.journal.impl.JournalImpl
> (org.apache.activemq.artemis.core.replication.ReplicatedJournal and
> org.apache.activemq.artemis.core.journal.impl.JournalImpl are in unnamed
> module of loader java.net.URLClassLoader @73d16e93){code}
>
> See attached screenshot of the Artemis console for additional details.
>
> *Configuration details:*
> * Cluster of Artemis primary/backup groups and with replication ha-policy
> (ZK)
>
> *Reproduction scenario:*
> With a brand new primary/backup group with replica :
> * Start primary and backup nodes
> * The JMX replay command works well on primary
> * Stop the primary node, backup becomes live
> * Restart the primary, it becomes live again (failback is enabled)
> * At this step, the reuse of the replay command on the primary trigger the
> ClassCastException
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923169=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923169
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 18:56
Start Date: 12/Jun/24 18:56
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2163705211
at least the -Ptests testsuite (complete one) ran fine.
Issue Time Tracking
---
Worklog Id: (was: 923169)
Time Spent: 1h 20m (was: 1h 10m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923164=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923164
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 17:58
Start Date: 12/Jun/24 17:58
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1636884171
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -160,15 +172,7 @@ public Collection getMatchingBindings(final
SimpleString address) throw
@Override
public Collection getDirectBindings(final SimpleString address)
throws Exception {
SimpleString realAddress = CompositeAddress.extractAddressName(address);
- Collection bindings = new ArrayList<>();
-
- nameMap.forEach((bindingUniqueName, bindingAddressPair) -> {
- if (bindingAddressPair.getA().getAddress().equals(realAddress)) {
-bindings.add(bindingAddressPair.getA());
- }
- });
-
- return bindings;
+ return new ArrayList<>(directBindingMap.getOrDefault(realAddress,
Collections.emptyList()));
Review Comment:
It's a copy operation, and works efficiently internally (at least in JDK
17). We could do a null check instead and return a new list if null, but this
has to be a defensive copy since the tests will otherwise fail.
```
public ArrayList(Collection c) {
Object[] a = c.toArray();
if ((size = a.length) != 0) {
if (c.getClass() == ArrayList.class) {
elementData = a;
} else {
elementData = Arrays.copyOf(a, size, Object[].class);
}
} else {
// replace with empty array.
elementData = EMPTY_ELEMENTDATA;
}
}
```
Issue Time Tracking
---
Worklog Id: (was: 923164)
Time Spent: 1h 10m (was: 1h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923157=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923157
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 17:01
Start Date: 12/Jun/24 17:01
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1636813616
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -160,15 +172,7 @@ public Collection getMatchingBindings(final
SimpleString address) throw
@Override
public Collection getDirectBindings(final SimpleString address)
throws Exception {
SimpleString realAddress = CompositeAddress.extractAddressName(address);
- Collection bindings = new ArrayList<>();
-
- nameMap.forEach((bindingUniqueName, bindingAddressPair) -> {
- if (bindingAddressPair.getA().getAddress().equals(realAddress)) {
-bindings.add(bindingAddressPair.getA());
- }
- });
-
- return bindings;
+ return new ArrayList<>(directBindingMap.getOrDefault(realAddress,
Collections.emptyList()));
Review Comment:
It seems rather odd to return a new ArrayList that's wrapping a potentially
immutable empty list. This should probably be made a bit smarter.
Issue Time Tracking
---
Worklog Id: (was: 923157)
Time Spent: 1h (was: 50m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923156=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923156
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 16:58
Start Date: 12/Jun/24 16:58
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2163510246
@joshb1050 there's a complete test suite that you can run with -Ptests.
The CI in Jenkins runs a limited version of the test suite for basic
validation.
For more through verification I run the entire test suite but I wouldn't
have reousrces for such a long process in the public CI from GitHub.
Issue Time Tracking
---
Worklog Id: (was: 923156)
Time Spent: 50m (was: 40m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923144=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923144
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 14:17
Start Date: 12/Jun/24 14:17
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2163134836
@clebertsuconic I believe I have fixed, though I wasn't able to see all of
those test failures when running locally (and it shows me as the CI passing as
well).
This is needed because each time one connection disconnects, say, with a few
thousand consumers, the `TempQueueCleanerUpper` needs to clean each of these
up, and it invokes `getDirectBindings` for each—so then this ends up being `O(k
* n)` where `k` is the number of queues on the server and `n` is the number of
consumers on the connection. It completely stops the server from functioning,
and seems to be a blocker for any setup that has a few hundred thousand plus
temp queues.
Issue Time Tracking
---
Worklog Id: (was: 923144)
Time Spent: 40m (was: 0.5h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923137=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923137
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 13:00
Start Date: 12/Jun/24 13:00
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2162952102
there are a few test failures:
Test /
org.apache.activemq.artemis.tests.integration.cli.AddressCommandTest.testForceDeleteAddressWhenExistsQueues
Test /
org.apache.activemq.artemis.tests.integration.addressing.TwoWaysRemoveAddressTest.testDeadLock
Test /
org.apache.activemq.artemis.tests.integration.ra.ActiveMQMessageHandlerTest.testSimpleMessageReceivedOnQueueManyMessagesAndInterruptTimeout
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testUnsubscribe
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testCreateSubscriber_1
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testCreateSubscriber_2
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testDurableSubscriber
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testCreateDurableSubscriber_1
Test /
org.objectweb.jtests.jms.conform.session.TopicSessionTest.testCreateDurableSubscriber_2
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateTemporaryTopicOnQueueSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateQueueOnTopicSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateBrowserOnTopicSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testUnsubscribeOnQueueSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateTemporaryQueueOnTopicSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateDurableSubscriberOnQueueSession
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateDurableConnectionConsumerOnQueueConnection
Test /
org.objectweb.jtests.jms.conform.session.UnifiedSessionTest.testCreateTopicOnQueueSession
Test /
org.objectweb.jtests.jms.conform.topic.TemporaryTopicTest.testTemporaryTopic
Test /
org.apache.activemq.artemis.tests.integration.amqp.connect.AMQPFederationAddressPolicyTest.testFederationHandlesAddressDeletedAndConsumerRecreates
Test /
org.apache.activemq.artemis.tests.integration.amqp.connect.AMQPFederationAddressPolicyTest.testRemoteBrokerClosesFederationReceiverAfterAddressRemoved
Test /
org.apache.activemq.artemis.tests.integration.cluster.distribution.SimpleSymmetricClusterTest.testDeleteAddress
Test /
org.apache.activemq.artemis.tests.integration.cluster.distribution.SymmetricClusterWithDiscoveryTest.testStartStopServers
Why you need this optimization? Are you constantly querying for the
destination on a producer or consumer?
Issue Time Tracking
---
Worklog Id: (was: 923137)
Time Spent: 20m (was: 10m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923138=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923138
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 13:00
Start Date: 12/Jun/24 13:00
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2162952912
Why you need this optimization? are you querying the queue every time you
produce?
Issue Time Tracking
---
Worklog Id: (was: 923138)
Time Spent: 0.5h (was: 20m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4795) Enforce queue filter when sending to FQQN
[ https://issues.apache.org/jira/browse/ARTEMIS-4795?focusedWorklogId=923124=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923124 ] ASF GitHub Bot logged work on ARTEMIS-4795: --- Author: ASF GitHub Bot Created on: 12/Jun/24 12:26 Start Date: 12/Jun/24 12:26 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4958: URL: https://github.com/apache/activemq-artemis/pull/4958 Issue Time Tracking --- Worklog Id: (was: 923124) Time Spent: 20m (was: 10m) > Enforce queue filter when sending to FQQN > - > > Key: ARTEMIS-4795 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4795 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When sending a message directly to an FQQN the queue's filter is not enforced > on the message which is sent. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
[ https://issues.apache.org/jira/browse/ARTEMIS-4813?focusedWorklogId=923081=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923081 ] ASF GitHub Bot logged work on ARTEMIS-4813: --- Author: ASF GitHub Bot Created on: 12/Jun/24 04:31 Start Date: 12/Jun/24 04:31 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4971: URL: https://github.com/apache/activemq-artemis/pull/4971 Issue Time Tracking --- Worklog Id: (was: 923081) Time Spent: 20m (was: 10m) > LargeMessages could lose a body while in sync if backup becomes activated > - > > Key: ARTEMIS-4813 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a regression because of ARTEMIS-4784 > If a large message is received while synchronization still happening, and if > the backup becomes online right away you may lose partial of the large > message. > testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4780) Artemis web console does not ever set 'artemisJmxDomain' in localStorage
[
https://issues.apache.org/jira/browse/ARTEMIS-4780?focusedWorklogId=923066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923066
]
ASF GitHub Bot logged work on ARTEMIS-4780:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 03:18
Start Date: 12/Jun/24 03:18
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #18:
URL:
https://github.com/apache/activemq-artemis-console/pull/18#issuecomment-2162027006
@andytaylor Up to you—whichever makes most sense. Thanks for tackling!
Issue Time Tracking
---
Worklog Id: (was: 923066)
Time Spent: 1h 20m (was: 1h 10m)
> Artemis web console does not ever set 'artemisJmxDomain' in localStorage
>
>
> Key: ARTEMIS-4780
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4780
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.32.0
>Reporter: Josh Byster
>Assignee: Andy Taylor
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We relocate our artemis packages as part of our shading process.
> I did set up:
>
> {code:java}
> aActiveMQServer.getConfiguration().setJMXDomain("com.abc.shaded.org.apache.activemq.artemis");
> {code}
> However the web console does not show up. I noticed in the code it's because
> we try to read in localStorage['artemisJmxDomain'] but never actually set it
> as far as I can tell. Thus we always default to org.apache.activemq.artemis.
> Everything works properly when setting localStorage['artemisJmxDomain'] =
> "com.abc.shaded.org.apache.activemq.artemis"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923065
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 03:14
Start Date: 12/Jun/24 03:14
Worklog Time Spent: 10m
Work Description: joshb1050 opened a new pull request, #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972
Currently, with 500K+ queues, the cleanup step of TempQueueCleanerUpper
requires invoking WildcardAddressManager#getDirectBindings, which is O(k) in
the number of queues.
From method profiling, this can consume up to 95% of our CPU time when
needing to clean up many of these.
Add a new map to keep track of the direct bindings, and add a test assertion
that fails if we don't properly remove it.
Issue Time Tracking
---
Worklog Id: (was: 923065)
Remaining Estimate: 0h
Time Spent: 10m
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923046=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923046
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 22:54
Start Date: 11/Jun/24 22:54
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161730473
@jbertram thank you—it's strange since I did run `mvn checkstyle:check` and
`mvn -Pdev install` and both passed with the checkstyle error. It's also
unclear given that `check` passed for 2 of the 3 failures. I have corrected the
latest one that I see on CI though.
Issue Time Tracking
---
Worklog Id: (was: 923046)
Time Spent: 1h 50m (was: 1h 40m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
[ https://issues.apache.org/jira/browse/ARTEMIS-4813?focusedWorklogId=923044=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923044 ] ASF GitHub Bot logged work on ARTEMIS-4813: --- Author: ASF GitHub Bot Created on: 11/Jun/24 22:20 Start Date: 11/Jun/24 22:20 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4971: URL: https://github.com/apache/activemq-artemis/pull/4971 This is a regressio after ARTEMIS-4784 Issue Time Tracking --- Worklog Id: (was: 923044) Remaining Estimate: 0h Time Spent: 10m > LargeMessages could lose a body while in sync if backup becomes activated > - > > Key: ARTEMIS-4813 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This is a regression because of ARTEMIS-4784 > If a large message is received while synchronization still happening, and if > the backup becomes online right away you may lose partial of the large > message. > testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923041=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923041
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 22:00
Start Date: 11/Jun/24 22:00
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161671151
For what it's worth you can run checkstyle locally using:
```
mvn -Pdev install
```
See the [hacking
guide](https://activemq.apache.org/components/artemis/documentation/hacking-guide/#using-the-dev-profile)
for more details.
Issue Time Tracking
---
Worklog Id: (was: 923041)
Time Spent: 1h 40m (was: 1.5h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923039=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923039
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:47
Start Date: 11/Jun/24 21:47
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161654314
Checkstyle is fixed now as well.
Issue Time Tracking
---
Worklog Id: (was: 923039)
Time Spent: 1.5h (was: 1h 20m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923037=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923037
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:45
Start Date: 11/Jun/24 21:45
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635514051
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
This is done.
Issue Time Tracking
---
Worklog Id: (was: 923037)
Time Spent: 1h 10m (was: 1h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923038=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923038
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:45
Start Date: 11/Jun/24 21:45
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635514337
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/AddressSettings.java:
##
@@ -1604,6 +1619,10 @@ public void decode(ActiveMQBuffer buffer, boolean
tryCompatible) {
prefetchPageMessages = BufferHelper.readNullableInteger(buffer);
}
+ if (buffer.readableBytes() > 0) {
+ intermediateMessageBufferInitialSize =
BufferHelper.readNullableInteger(buffer);
+ }
+
Review Comment:
Missed that—done now.
Issue Time Tracking
---
Worklog Id: (was: 923038)
Time Spent: 1h 20m (was: 1h 10m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923034=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923034
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:22
Start Date: 11/Jun/24 21:22
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635493471
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
Specify the default value here as with the other elements (i.e. `8192`).
Issue Time Tracking
---
Worklog Id: (was: 923034)
Time Spent: 1h (was: 50m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923033=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923033
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:20
Start Date: 11/Jun/24 21:20
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635493471
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
Specify the default value here as with the other elements.
Issue Time Tracking
---
Worklog Id: (was: 923033)
Time Spent: 50m (was: 40m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923032=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923032
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:19
Start Date: 11/Jun/24 21:19
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635492310
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/AddressSettings.java:
##
@@ -1604,6 +1619,10 @@ public void decode(ActiveMQBuffer buffer, boolean
tryCompatible) {
prefetchPageMessages = BufferHelper.readNullableInteger(buffer);
}
+ if (buffer.readableBytes() > 0) {
+ intermediateMessageBufferInitialSize =
BufferHelper.readNullableInteger(buffer);
+ }
+
Review Comment:
Notice the comment below. This code should be removed.
Issue Time Tracking
---
Worklog Id: (was: 923032)
Time Spent: 40m (was: 0.5h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.111.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923031=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923031 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 21:12 Start Date: 11/Jun/24 21:12 Worklog Time Spent: 10m Work Description: jbertram merged PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969 Issue Time Tracking --- Worklog Id: (was: 923031) Time Spent: 40m (was: 0.5h) > Upgrade Netty to 4.1.111.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.110.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923022=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923022 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 19:27 Start Date: 11/Jun/24 19:27 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969#issuecomment-2161463400 Actually 4.1.111.Final has already been released so just update your PR and this problem should go away. Issue Time Tracking --- Worklog Id: (was: 923022) Time Spent: 0.5h (was: 20m) > Upgrade Netty to 4.1.110.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.110.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923021=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923021 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 19:22 Start Date: 11/Jun/24 19:22 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969#issuecomment-2161456131 Looks like we may need to wait for 4.1.111.Final in order to get https://github.com/netty/netty/issues/14080. Issue Time Tracking --- Worklog Id: (was: 923021) Time Spent: 20m (was: 10m) > Upgrade Netty to 4.1.110.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4812?focusedWorklogId=922981=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922981 ] ASF GitHub Bot logged work on ARTEMIS-4812: --- Author: ASF GitHub Bot Created on: 11/Jun/24 16:03 Start Date: 11/Jun/24 16:03 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4970: URL: https://github.com/apache/activemq-artemis/pull/4970 Issue Time Tracking --- Worklog Id: (was: 922981) Time Spent: 20m (was: 10m) > PageCursorInfo should be cleared on its Maps when page is marked as complete > > > Key: ARTEMIS-4812 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Say you have a paged destination where there is a lazy consumer. The other > queues will keep consuming, and they will mark a page as complete. However > PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared > upon completion otherwise they will only be GCed when the page file is > removed and the entries for PageCursorInfo removed. > IntObjectHashMap also keeps an array of integers in memory and it won't > remove it when all elements are removed. to the reference to IntObjectHashMap > has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?focusedWorklogId=922974=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922974 ] ASF GitHub Bot logged work on AMQ-9506: --- Author: ASF GitHub Bot Created on: 11/Jun/24 15:27 Start Date: 11/Jun/24 15:27 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1231: URL: https://github.com/apache/activemq/pull/1231 Issue Time Tracking --- Worklog Id: (was: 922974) Time Spent: 20m (was: 10m) > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4812?focusedWorklogId=922971=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922971 ] ASF GitHub Bot logged work on ARTEMIS-4812: --- Author: ASF GitHub Bot Created on: 11/Jun/24 14:23 Start Date: 11/Jun/24 14:23 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4970: URL: https://github.com/apache/activemq-artemis/pull/4970 this could lead to OME if a lazy consumer is there for a long time with all pages being removed. Issue Time Tracking --- Worklog Id: (was: 922971) Remaining Estimate: 0h Time Spent: 10m > PageCursorInfo should be cleared on its Maps when page is marked as complete > > > Key: ARTEMIS-4812 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Say you have a paged destination where there is a lazy consumer. The other > queues will keep consuming, and they will mark a page as complete. However > PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared > upon completion otherwise they will only be GCed when the page file is > removed and the entries for PageCursorInfo removed. > IntObjectHashMap also keeps an array of integers in memory and it won't > remove it when all elements are removed. to the reference to IntObjectHashMap > has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?focusedWorklogId=922928=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922928 ] ASF GitHub Bot logged work on AMQ-9498: --- Author: ASF GitHub Bot Created on: 11/Jun/24 09:50 Start Date: 11/Jun/24 09:50 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1229: URL: https://github.com/apache/activemq/pull/1229 Issue Time Tracking --- Worklog Id: (was: 922928) Time Spent: 40m (was: 0.5h) > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4796) Simplify SimpleString API
[
https://issues.apache.org/jira/browse/ARTEMIS-4796?focusedWorklogId=922873=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922873
]
ASF GitHub Bot logged work on ARTEMIS-4796:
---
Author: ASF GitHub Bot
Created on: 10/Jun/24 21:03
Start Date: 10/Jun/24 21:03
Worklog Time Spent: 10m
Work Description: tabish121 merged PR #4967:
URL: https://github.com/apache/activemq-artemis/pull/4967
Issue Time Tracking
---
Worklog Id: (was: 922873)
Time Spent: 3.5h (was: 3h 20m)
> Simplify SimpleString API
> -
>
> Key: ARTEMIS-4796
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4796
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Instead of using the verbosely named {{toSimpleString}} static factory method
> (and its overloaded counterparts), {{SimpleString}} should provide {{of}}
> implementations. This change would make the code more concise and readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=922855=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922855
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 10/Jun/24 18:12
Start Date: 10/Jun/24 18:12
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2159000754
Thanks @jbertram! I have updated my PR to make this configurable on a
per-address basis and via XML as well. I have also added tests for the
functionality. Please let me know if there is a different approach I should be
taking here.
Issue Time Tracking
---
Worklog Id: (was: 922855)
Time Spent: 0.5h (was: 20m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.110.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=922846=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922846 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 10/Jun/24 16:21 Start Date: 10/Jun/24 16:21 Worklog Time Spent: 10m Work Description: ehsavoie opened a new pull request, #4969: URL: https://github.com/apache/activemq-artemis/pull/4969 (no comment) Issue Time Tracking --- Worklog Id: (was: 922846) Remaining Estimate: 0h Time Spent: 10m > Upgrade Netty to 4.1.110.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4800) Simplify QueueConfiguration API
[ https://issues.apache.org/jira/browse/ARTEMIS-4800?focusedWorklogId=922832=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922832 ] ASF GitHub Bot logged work on ARTEMIS-4800: --- Author: ASF GitHub Bot Created on: 10/Jun/24 14:58 Start Date: 10/Jun/24 14:58 Worklog Time Spent: 10m Work Description: tabish121 merged PR #4964: URL: https://github.com/apache/activemq-artemis/pull/4964 Issue Time Tracking --- Worklog Id: (was: 922832) Time Spent: 0.5h (was: 20m) > Simplify QueueConfiguration API > --- > > Key: ARTEMIS-4800 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4800 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4780) Artemis web console does not ever set 'artemisJmxDomain' in localStorage
[
https://issues.apache.org/jira/browse/ARTEMIS-4780?focusedWorklogId=922816=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922816
]
ASF GitHub Bot logged work on ARTEMIS-4780:
---
Author: ASF GitHub Bot
Created on: 10/Jun/24 12:58
Start Date: 10/Jun/24 12:58
Worklog Time Spent: 10m
Work Description: andytaylor commented on PR #18:
URL:
https://github.com/apache/activemq-artemis-console/pull/18#issuecomment-2158283290
I have made it configurable and this time actually use it, I can reopen this
or raise a new PR, wdyt?
Issue Time Tracking
---
Worklog Id: (was: 922816)
Time Spent: 1h 10m (was: 1h)
> Artemis web console does not ever set 'artemisJmxDomain' in localStorage
>
>
> Key: ARTEMIS-4780
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4780
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.32.0
>Reporter: Josh Byster
>Assignee: Andy Taylor
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We relocate our artemis packages as part of our shading process.
> I did set up:
>
> {code:java}
> aActiveMQServer.getConfiguration().setJMXDomain("com.abc.shaded.org.apache.activemq.artemis");
> {code}
> However the web console does not show up. I noticed in the code it's because
> we try to read in localStorage['artemisJmxDomain'] but never actually set it
> as far as I can tell. Thus we always default to org.apache.activemq.artemis.
> Everything works properly when setting localStorage['artemisJmxDomain'] =
> "com.abc.shaded.org.apache.activemq.artemis"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922811=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922811 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 10/Jun/24 12:50 Start Date: 10/Jun/24 12:50 Worklog Time Spent: 10m Work Description: gtully commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2158260584 > @gtully Do you know of any current test that demonstrates (or at least includes) having to wait for a lease expiry for the JDBC case? https://github.com/apache/activemq-artemis/blob/362dbd11ac132e66f7bce99eb0fb4aa020346210/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcLeaseLockTest.java#L218 that looks like it should have to wait. Issue Time Tracking --- Worklog Id: (was: 922811) Time Spent: 1h (was: 50m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922794=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922794 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 10/Jun/24 11:51 Start Date: 10/Jun/24 11:51 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2158137960 @gtully Do you know of any current test that demonstrates (or at least includes) having to wait for a lease expiry for the JDBC case? Issue Time Tracking --- Worklog Id: (was: 922794) Time Spent: 50m (was: 40m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=922678=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922678
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 21:57
Start Date: 07/Jun/24 21:57
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2155625196
Thanks for the PR!
I think this would be better as an address-setting so you could easily
configure large swaths of queues. Right now there's no way to configure this
via `broker.xml`. It can only be configured if you're directly creating the
queue(s) programmatically.
Lastly, there's no tests or documentation for this new setting. Tests are
mandatory to ensure the functionality works properly and to mitigate future
regressions.
Issue Time Tracking
---
Worklog Id: (was: 922678)
Time Spent: 20m (was: 10m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4800) Simplify QueueConfiguration API
[ https://issues.apache.org/jira/browse/ARTEMIS-4800?focusedWorklogId=922667=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922667 ] ASF GitHub Bot logged work on ARTEMIS-4800: --- Author: ASF GitHub Bot Created on: 07/Jun/24 21:18 Start Date: 07/Jun/24 21:18 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4964: URL: https://github.com/apache/activemq-artemis/pull/4964#issuecomment-2155566464 This looks good,I looked for awhile and didn't see any missed references. Issue Time Tracking --- Worklog Id: (was: 922667) Time Spent: 20m (was: 10m) > Simplify QueueConfiguration API > --- > > Key: ARTEMIS-4800 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4800 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4796) Simplify SimpleString API
[
https://issues.apache.org/jira/browse/ARTEMIS-4796?focusedWorklogId=922662=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922662
]
ASF GitHub Bot logged work on ARTEMIS-4796:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 21:10
Start Date: 07/Jun/24 21:10
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4967:
URL:
https://github.com/apache/activemq-artemis/pull/4967#issuecomment-218579
This is a follow-up from #4959 to address some comments from @gemmellr.
Issue Time Tracking
---
Worklog Id: (was: 922662)
Time Spent: 3h 20m (was: 3h 10m)
> Simplify SimpleString API
> -
>
> Key: ARTEMIS-4796
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4796
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Instead of using the verbosely named {{toSimpleString}} static factory method
> (and its overloaded counterparts), {{SimpleString}} should provide {{of}}
> implementations. This change would make the code more concise and readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4796) Simplify SimpleString API
[
https://issues.apache.org/jira/browse/ARTEMIS-4796?focusedWorklogId=922660=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922660
]
ASF GitHub Bot logged work on ARTEMIS-4796:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 21:10
Start Date: 07/Jun/24 21:10
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4967:
URL: https://github.com/apache/activemq-artemis/pull/4967
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 922660)
Time Spent: 3h 10m (was: 3h)
> Simplify SimpleString API
> -
>
> Key: ARTEMIS-4796
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4796
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Instead of using the verbosely named {{toSimpleString}} static factory method
> (and its overloaded counterparts), {{SimpleString}} should provide {{of}}
> implementations. This change would make the code more concise and readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=922644=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922644
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 19:40
Start Date: 07/Jun/24 19:40
Worklog Time Spent: 10m
Work Description: joshb1050 opened a new pull request, #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966
In some setups, there could be a few hundred thousand queues that are
created due to many consumers that are connecting. However, most of these are
empty and stay empty for the entire day since there aren't necessarily messages
to be sent. The 8K `intermediateMessageReferences` instantiates an `64KB`
buffer (`Object[]`). This means we have large allocation and live heap that
ultimately remains empty for almost the entire day.
In this commit, we introduce `intermediate-message-buffer-initial-size`,
which defaults to the current value of `8192`. It can be set programmatically
via
`QueueConfiguration#setIntermediateMessageBufferInitialSize(int)`.
Note that this must be a power of 2.
Issue Time Tracking
---
Worklog Id: (was: 922644)
Remaining Estimate: 0h
Time Spent: 10m
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922641=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922641 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 07/Jun/24 19:35 Start Date: 07/Jun/24 19:35 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2155417744 Thanks for your feedback @gtully If I am not mistaken the first case should be addressed already, where the coordination-id takes precedence over the configured nodeID. It should be verified by: `org.apache.activemq.artemis.tests.integration.replication.LockManagerReplicationTest#testPrimaryPeers()` let me know if I misunderstood though. I will take a look at the JDBC case, thanks! Issue Time Tracking --- Worklog Id: (was: 922641) Time Spent: 40m (was: 0.5h) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4798) Address Size differs between Mirror and Source queue, leading to OME scenarios
[ https://issues.apache.org/jira/browse/ARTEMIS-4798?focusedWorklogId=922601=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922601 ] ASF GitHub Bot logged work on ARTEMIS-4798: --- Author: ASF GitHub Bot Created on: 07/Jun/24 15:10 Start Date: 07/Jun/24 15:10 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4961: URL: https://github.com/apache/activemq-artemis/pull/4961 Issue Time Tracking --- Worklog Id: (was: 922601) Time Spent: 0.5h (was: 20m) > Address Size differs between Mirror and Source queue, leading to OME scenarios > -- > > Key: ARTEMIS-4798 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4798 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Say you configure the broker to mirror. > You stop the mirror target (shutdown the server). > Now you send and consume from a destination, keeping the destination's size > close to zero. > You may get an OME on that situation. > This is because the calculation on the address-size only computes the main > body of the message at the original queue. While Mirror will only get a small > portion on the reference, in such cases you would end up with lazy starts in > paging... and things could go wrong. > To fix that, both Mirror and the source queue should get the body portion of > the size. > Basically while we route the message, we check if the address is not the > original and the Mirror SNF should also get the same portion of the size in > its calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=922600=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922600
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 15:07
Start Date: 07/Jun/24 15:07
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2155033417
I believe the use-case here only involves cluster nodes and the core
connections between them. Therefore, I don't think AMQP is in view.
Issue Time Tracking
---
Worklog Id: (was: 922600)
Time Spent: 1h 20m (was: 1h 10m)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=922599=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922599
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 15:01
Start Date: 07/Jun/24 15:01
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2155022268
If this is an issue in Core, it will be an issue in AMQP as well. we should
make sure AMQP also takes care of this?
WDYT @jbertram @gemmellr @gtully @tabish121 ?
Issue Time Tracking
---
Worklog Id: (was: 922599)
Time Spent: 1h 10m (was: 1h)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4802) Deprecated master,slave,check-for-live-server tags in examples/features/ha/replicated-failback sample
[
https://issues.apache.org/jira/browse/ARTEMIS-4802?focusedWorklogId=922598=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922598
]
ASF GitHub Bot logged work on ARTEMIS-4802:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:58
Start Date: 07/Jun/24 14:58
Worklog Time Spent: 10m
Work Description: gemmellr closed pull request #10: ARTEMIS-4802 - Fixing
the use of depricating tags master,slave,check-…
URL: https://github.com/apache/activemq-artemis-examples/pull/10
Issue Time Tracking
---
Worklog Id: (was: 922598)
Time Spent: 0.5h (was: 20m)
> Deprecated master,slave,check-for-live-server tags in
> examples/features/ha/replicated-failback sample
> -
>
> Key: ARTEMIS-4802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4802
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: ActiveMQ-Artemis-Examples
>Affects Versions: 2.34.0
>Reporter: Susinda Perera
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting active mq ha samples it gives below log messages.
>
> {code:java}
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'master' is deprecated and will be removed in a future version. Use
> 'primary' instead. Consult the manual for details.
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'check-for-live-server' is deprecated and will be removed in a future
> version. Use 'check-for-active-server' instead. Consult the manual for
> details.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4802) Deprecated master,slave,check-for-live-server tags in examples/features/ha/replicated-failback sample
[
https://issues.apache.org/jira/browse/ARTEMIS-4802?focusedWorklogId=922597=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922597
]
ASF GitHub Bot logged work on ARTEMIS-4802:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:58
Start Date: 07/Jun/24 14:58
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #10:
URL:
https://github.com/apache/activemq-artemis-examples/pull/10#issuecomment-2155016832
I rebased your changes to the _development_ branch as per
[CONTRIBUTING.md](https://github.com/apache/activemq-artemis-examples/blob/main/CONTRIBUTING.md),
and I dropped the readme change as I'll make a general improvement around that
separately). Pushed in
https://github.com/apache/activemq-artemis-examples/commit/b8662f9a29d0579249d0239fd79f93fe4be99139.
Issue Time Tracking
---
Worklog Id: (was: 922597)
Time Spent: 20m (was: 10m)
> Deprecated master,slave,check-for-live-server tags in
> examples/features/ha/replicated-failback sample
> -
>
> Key: ARTEMIS-4802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4802
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: ActiveMQ-Artemis-Examples
>Affects Versions: 2.34.0
>Reporter: Susinda Perera
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When starting active mq ha samples it gives below log messages.
>
> {code:java}
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'master' is deprecated and will be removed in a future version. Use
> 'primary' instead. Consult the manual for details.
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'check-for-live-server' is deprecated and will be removed in a future
> version. Use 'check-for-active-server' instead. Consult the manual for
> details.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=922596=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922596
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:37
Start Date: 07/Jun/24 14:37
Worklog Time Spent: 10m
Work Description: iiliev2 commented on code in PR #4899:
URL: https://github.com/apache/activemq-artemis/pull/4899#discussion_r1631319204
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java:
##
@@ -408,10 +416,15 @@ public void endOfBatch(Object connectionID) {
}
private void doBufferReceived(final Packet packet) {
+ if (isHealthy && !isCorrectPing(packet)) {
+ isHealthy = false;
Review Comment:
Commenting this line out will effectively disable the fix. This will cause
the new test `ZeroPersistenceSymmetricalClusterTest` to fail.
Issue Time Tracking
---
Worklog Id: (was: 922596)
Time Spent: 1h (was: 50m)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=922595=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922595
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:36
Start Date: 07/Jun/24 14:36
Worklog Time Spent: 10m
Work Description: iiliev2 commented on code in PR #4899:
URL: https://github.com/apache/activemq-artemis/pull/4899#discussion_r1631317798
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java:
##
@@ -421,6 +434,34 @@ private void doBufferReceived(final Packet packet) {
}
}
+ private boolean isCorrectPing(Packet packet) {
+ if (packet.getType() != PING) {
+ return true;
Review Comment:
Commenting this line out will effectively disable the fix. This will cause
the new test `ZeroPersistenceSymmetricalClusterTest` to fail.
Issue Time Tracking
---
Worklog Id: (was: 922595)
Time Spent: 50m (was: 40m)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=922594=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922594
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:36
Start Date: 07/Jun/24 14:36
Worklog Time Spent: 10m
Work Description: iiliev2 commented on code in PR #4899:
URL: https://github.com/apache/activemq-artemis/pull/4899#discussion_r1631317798
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java:
##
@@ -421,6 +434,34 @@ private void doBufferReceived(final Packet packet) {
}
}
+ private boolean isCorrectPing(Packet packet) {
+ if (packet.getType() != PING) {
+ return true;
Review Comment:
Commenting this line out will effectively disable the fix. This will cause
the new test `ZeroPersistenceSymmetricalClusterTest` to fail.
Issue Time Tracking
---
Worklog Id: (was: 922594)
Time Spent: 40m (was: 0.5h)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4797) Failover connection references are not always cleaned up in NettyAcceptor, leaking memory
[
https://issues.apache.org/jira/browse/ARTEMIS-4797?focusedWorklogId=922592=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922592
]
ASF GitHub Bot logged work on ARTEMIS-4797:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:29
Start Date: 07/Jun/24 14:29
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4960:
URL:
https://github.com/apache/activemq-artemis/pull/4960#issuecomment-2154967424
@gemmellr That's possible...though I don't know how else to handle this. The
`connectionDestroyed` listener needs to be called for these but they aren't,
and we leak memory in the case where the exception callback is called first.
Issue Time Tracking
---
Worklog Id: (was: 922592)
Time Spent: 40m (was: 0.5h)
> Failover connection references are not always cleaned up in NettyAcceptor,
> leaking memory
> -
>
> Key: ARTEMIS-4797
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4797
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Reporter: Josh Byster
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I'm still trying to parse through exactly what conditions this occurs in,
> since I'm able to reproduce it in a very specific production setup but not in
> an isolated environment locally.
> For context, we have custom slow consumer detection that closes connection
> IDs with slow consumers. These connections are connected via failover
> transport using client ActiveMQ Classic 5.16.4 (OpenWire). This seems to be
> specific to Netty.
> It appears this specific order of events causes the connection to not get
> cleaned up and retained indefinitely on the broker. With frequent kicking of
> connections, this ends up causing the broker to eventually OOM.
> 1. Connection is created, {{ActiveMQServerChannelHandler}} is created as well
> 2. {{ActiveMQServerChannelHandler#createConnection}} is called, {{active}}
> flag is set {{true}}.
> 3. A few minutes go by, then we call
> {{ActiveMQServerControl#closeConnectionWithID}} with the connection ID.
> 4. {{ActiveMQChannelHandler#exceptionCaught}} gets called—*this is the key
> point that causes issues*. The connection is cleaned up if and only if this
> is *not* called. The root cause of the exception is
> {{AbstractChannel.close(ChannelPromise)}}, however the comment above it says
> this is normal for failover.
> 5. The {{active}} flag is set to {{false}}.
> 6. {{ActiveMQChannelHandler#channelInactive}} gets called, but does *not*
> call {{listener.connectionDestroyed}} since the {{active}} flag is false.
> 7. The connection is never removed from the {{connections}} map in
> {{NettyAcceptor}}, causing a leak and eventual OOM of the broker if it
> happens frequently enough.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4797) Failover connection references are not always cleaned up in NettyAcceptor, leaking memory
[
https://issues.apache.org/jira/browse/ARTEMIS-4797?focusedWorklogId=922588=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922588
]
ASF GitHub Bot logged work on ARTEMIS-4797:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 14:00
Start Date: 07/Jun/24 14:00
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #4960:
URL:
https://github.com/apache/activemq-artemis/pull/4960#issuecomment-2154908286
Your Jira and PR comments are aimed at Acceptor behaviour, and you note on
the Jira that you are using Openwire clients...however the changed bits are
also used by the Artemis Core client. I'm not familiar with this code, but it
seems to me like the change could result in the connectionDestroyed listener
callback being called for clients when it wouldnt currently be, after the
connectionException listener callback could already have been called,
potentially causing a double-failover or other weirdness?
Issue Time Tracking
---
Worklog Id: (was: 922588)
Time Spent: 0.5h (was: 20m)
> Failover connection references are not always cleaned up in NettyAcceptor,
> leaking memory
> -
>
> Key: ARTEMIS-4797
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4797
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Reporter: Josh Byster
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm still trying to parse through exactly what conditions this occurs in,
> since I'm able to reproduce it in a very specific production setup but not in
> an isolated environment locally.
> For context, we have custom slow consumer detection that closes connection
> IDs with slow consumers. These connections are connected via failover
> transport using client ActiveMQ Classic 5.16.4 (OpenWire). This seems to be
> specific to Netty.
> It appears this specific order of events causes the connection to not get
> cleaned up and retained indefinitely on the broker. With frequent kicking of
> connections, this ends up causing the broker to eventually OOM.
> 1. Connection is created, {{ActiveMQServerChannelHandler}} is created as well
> 2. {{ActiveMQServerChannelHandler#createConnection}} is called, {{active}}
> flag is set {{true}}.
> 3. A few minutes go by, then we call
> {{ActiveMQServerControl#closeConnectionWithID}} with the connection ID.
> 4. {{ActiveMQChannelHandler#exceptionCaught}} gets called—*this is the key
> point that causes issues*. The connection is cleaned up if and only if this
> is *not* called. The root cause of the exception is
> {{AbstractChannel.close(ChannelPromise)}}, however the comment above it says
> this is normal for failover.
> 5. The {{active}} flag is set to {{false}}.
> 6. {{ActiveMQChannelHandler#channelInactive}} gets called, but does *not*
> call {{listener.connectionDestroyed}} since the {{active}} flag is false.
> 7. The connection is never removed from the {{connections}} map in
> {{NettyAcceptor}}, causing a leak and eventual OOM of the broker if it
> happens frequently enough.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4796) Simplify SimpleString API
[
https://issues.apache.org/jira/browse/ARTEMIS-4796?focusedWorklogId=922540=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922540
]
ASF GitHub Bot logged work on ARTEMIS-4796:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 10:44
Start Date: 07/Jun/24 10:44
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #4959:
URL:
https://github.com/apache/activemq-artemis/pull/4959#issuecomment-2154566142
Same general review comment as last time. There are still several references
to toSimpleString (outside compatibility tests). There is now-unused deprecated
stuff that isn't tested.
Issue Time Tracking
---
Worklog Id: (was: 922540)
Time Spent: 3h (was: 2h 50m)
> Simplify SimpleString API
> -
>
> Key: ARTEMIS-4796
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4796
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Instead of using the verbosely named {{toSimpleString}} static factory method
> (and its overloaded counterparts), {{SimpleString}} should provide {{of}}
> implementations. This change would make the code more concise and readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4799) Broker Connection Receiver attach handled incorrectly
[ https://issues.apache.org/jira/browse/ARTEMIS-4799?focusedWorklogId=922536=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922536 ] ASF GitHub Bot logged work on ARTEMIS-4799: --- Author: ASF GitHub Bot Created on: 07/Jun/24 10:21 Start Date: 07/Jun/24 10:21 Worklog Time Spent: 10m Work Description: gemmellr merged PR #4963: URL: https://github.com/apache/activemq-artemis/pull/4963 Issue Time Tracking --- Worklog Id: (was: 922536) Time Spent: 20m (was: 10m) > Broker Connection Receiver attach handled incorrectly > - > > Key: ARTEMIS-4799 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4799 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The AMQP Broker Connection Receiver configuration creates a receiver for > messages from a remote AMQP source however the attach handling is not > properly handled leading to a receiver that thinks it is operating as an > opened anonymous relay sender meaning it only routes messages with a set 'To' > field in the properties. The receiver attach should be using the locally > defined target as the address for incoming messages and ignore an 'To' value > in the message properties. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4802) Depricated master,slave,check-for-live-server tags in examples/features/ha/replicated-failback sample
[
https://issues.apache.org/jira/browse/ARTEMIS-4802?focusedWorklogId=922450=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922450
]
ASF GitHub Bot logged work on ARTEMIS-4802:
---
Author: ASF GitHub Bot
Created on: 07/Jun/24 05:48
Start Date: 07/Jun/24 05:48
Worklog Time Spent: 10m
Work Description: susinda opened a new pull request, #10:
URL: https://github.com/apache/activemq-artemis-examples/pull/10
Fixing the use of deprecating tags master, slave, check-for-live-server in
ha/replicated-failback sample with their new values
primary, backup and check-for-active-server
Issue Time Tracking
---
Worklog Id: (was: 922450)
Remaining Estimate: 0h
Time Spent: 10m
> Depricated master,slave,check-for-live-server tags in
> examples/features/ha/replicated-failback sample
> -
>
> Key: ARTEMIS-4802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4802
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: ActiveMQ-Artemis-Examples
>Affects Versions: 2.34.0
>Reporter: Susinda Perera
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When starting active mq ha samples it gives below log messages.
>
> {code:java}
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'master' is deprecated and will be removed in a future version. Use
> 'primary' instead. Consult the manual for details.
> INFO [org.apache.activemq.artemis.core.server] AMQ221038: Configuration
> option 'check-for-live-server' is deprecated and will be removed in a future
> version. Use 'check-for-active-server' instead. Consult the manual for
> details.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4801) AMQP Session address query cache can have invalid state for long lived sessions
[ https://issues.apache.org/jira/browse/ARTEMIS-4801?focusedWorklogId=922430=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922430 ] ASF GitHub Bot logged work on ARTEMIS-4801: --- Author: ASF GitHub Bot Created on: 07/Jun/24 01:07 Start Date: 07/Jun/24 01:07 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4965: URL: https://github.com/apache/activemq-artemis/pull/4965 Issue Time Tracking --- Worklog Id: (was: 922430) Time Spent: 20m (was: 10m) > AMQP Session address query cache can have invalid state for long lived > sessions > --- > > Key: ARTEMIS-4801 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4801 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The AMQPSessionCallback retains a map of AddressQueryResult instances for > previous address checks. This map is not updated if the state of broker > addresses changes, neither addresses added, removed or updated states are > reflected in the cache. This leads to issues for long running sessions where > a link attach may fail for a non-existent address and on a later attempt > should succeed if the address was added but can't because the cache will > still hold the non-exists query result. Other scenarios are possible such as > an address removed and re-added with different routing type but the former > case is more serious. > The cache should be removed and if a similar optimization is actually found > to be needed a better mechanism should be chosen to avoid the issues found. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4801) AMQP Session address query cache can have invalid state for long lived sessions
[ https://issues.apache.org/jira/browse/ARTEMIS-4801?focusedWorklogId=922426=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922426 ] ASF GitHub Bot logged work on ARTEMIS-4801: --- Author: ASF GitHub Bot Created on: 06/Jun/24 20:54 Start Date: 06/Jun/24 20:54 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4965: URL: https://github.com/apache/activemq-artemis/pull/4965 When caching address query results the remote session can be blocked forever from creating links on an address if the "does not exist" value is cached since it is never updated again and will always report "does not exist" even if the address is added manually via management later. The cache state can cause other issues for long running sessions as well and should be removed to avoid attach failures for cases where the current broker state could allow the attach to succeed but the cached entry won't allow it. Issue Time Tracking --- Worklog Id: (was: 922426) Remaining Estimate: 0h Time Spent: 10m > AMQP Session address query cache can have invalid state for long lived > sessions > --- > > Key: ARTEMIS-4801 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4801 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The AMQPSessionCallback retains a map of AddressQueryResult instances for > previous address checks. This map is not updated if the state of broker > addresses changes, neither addresses added, removed or updated states are > reflected in the cache. This leads to issues for long running sessions where > a link attach may fail for a non-existent address and on a later attempt > should succeed if the address was added but can't because the cache will > still hold the non-exists query result. Other scenarios are possible such as > an address removed and re-added with different routing type but the former > case is more serious. > The cache should be removed and if a similar optimization is actually found > to be needed a better mechanism should be chosen to avoid the issues found. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4800) Simplify QueueConfiguration API
[ https://issues.apache.org/jira/browse/ARTEMIS-4800?focusedWorklogId=922424=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922424 ] ASF GitHub Bot logged work on ARTEMIS-4800: --- Author: ASF GitHub Bot Created on: 06/Jun/24 20:23 Start Date: 06/Jun/24 20:23 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4964: URL: https://github.com/apache/activemq-artemis/pull/4964 This commit does the following: - deprecate all QueueConfiguration ctors - add `of` static factory methods for all the deprecated ctors - replace any uses of the normal ctors with the `of` counterparts This makes the code more concise and readable. Issue Time Tracking --- Worklog Id: (was: 922424) Remaining Estimate: 0h Time Spent: 10m > Simplify QueueConfiguration API > --- > > Key: ARTEMIS-4800 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4800 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4799) Broker Connection Receiver attach handled incorrectly
[ https://issues.apache.org/jira/browse/ARTEMIS-4799?focusedWorklogId=922415=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922415 ] ASF GitHub Bot logged work on ARTEMIS-4799: --- Author: ASF GitHub Bot Created on: 06/Jun/24 17:48 Start Date: 06/Jun/24 17:48 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4963: URL: https://github.com/apache/activemq-artemis/pull/4963 The receiver attach in broker connection does not wait for the remote attach to arrive before creating the broker side receiver plumbing which leads to the broker treating the remote sender as an anonymous relay when it is not and should not be. Await the remote attach in response to the attach sent by the broker connection to finish the link setup but use the locally defined target address vs the remote to route the incoming messages. Issue Time Tracking --- Worklog Id: (was: 922415) Remaining Estimate: 0h Time Spent: 10m > Broker Connection Receiver attach handled incorrectly > - > > Key: ARTEMIS-4799 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4799 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The AMQP Broker Connection Receiver configuration creates a receiver for > messages from a remote AMQP source however the attach handling is not > properly handled leading to a receiver that thinks it is operating as an > opened anonymous relay sender meaning it only routes messages with a set 'To' > field in the properties. The receiver attach should be using the locally > defined target as the address for incoming messages and ignore an 'To' value > in the message properties. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4796) Simplify SimpleString API
[
https://issues.apache.org/jira/browse/ARTEMIS-4796?focusedWorklogId=922397=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922397
]
ASF GitHub Bot logged work on ARTEMIS-4796:
---
Author: ASF GitHub Bot
Created on: 06/Jun/24 15:53
Start Date: 06/Jun/24 15:53
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4959:
URL: https://github.com/apache/activemq-artemis/pull/4959
Issue Time Tracking
---
Worklog Id: (was: 922397)
Time Spent: 2h 50m (was: 2h 40m)
> Simplify SimpleString API
> -
>
> Key: ARTEMIS-4796
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4796
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Instead of using the verbosely named {{toSimpleString}} static factory method
> (and its overloaded counterparts), {{SimpleString}} should provide {{of}}
> implementations. This change would make the code more concise and readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
