[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] [Commented] (ARTEMIS-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
[ https://issues.apache.org/jira/browse/ARTEMIS-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854886#comment-17854886 ] ASF subversion and git services commented on ARTEMIS-4817: -- Commit a6ff05ecd7c83e28fe23092e62b10e1078221b57 in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a6ff05ecd7 ] ARTEMIS-4817 Check policy credits before checking parent credits 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. > 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] [Resolved] (ARTEMIS-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
[ https://issues.apache.org/jira/browse/ARTEMIS-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4817. -- Resolution: Fixed > 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] [Commented] (ARTEMIS-2892) Replication stopped working after many failovers
[
https://issues.apache.org/jira/browse/ARTEMIS-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854873#comment-17854873
]
ASF subversion and git services commented on ARTEMIS-2892:
--
Commit 58e8deac2b8d9c904d646e5bfb6ec0aff1596ba2 in activemq-artemis's branch
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=58e8deac2b ]
ARTEMIS-2892 Interrupted replication could lead to restart problems
> 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] [Commented] (ARTEMIS-2892) Replication stopped working after many failovers
[
https://issues.apache.org/jira/browse/ARTEMIS-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854833#comment-17854833
]
Clebert Suconic commented on ARTEMIS-2892:
--
I guess this is not happening any more.. Even a user I know that used to see
this can't reproduce it any more.
I'm dealing with the code though to make sure it wouldn't happen again.
I will commit the fix against this JIRA.
Let me know if anyone sees this issue or a similar issue to this?
> 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
>
>
> 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] [Commented] (ARTEMIS-4667) JMX Recovery operation triggers ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854791#comment-17854791
]
Jean-Pascal Briquet commented on ARTEMIS-4667:
--
Many thanks for the fix !
> 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] [Commented] (AMQ-9455) DestinationPolicy to support MessageInterceptorStrategy
[ https://issues.apache.org/jira/browse/AMQ-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854831#comment-17854831 ] ASF subversion and git services commented on AMQ-9455: -- Commit c465330be5e66fac40e7c73a74fd0cad9c5333f0 in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c465330be ] [AMQ-9455] DestinationPolicy support for MessageInterceptorStrategy > 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-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] [Commented] (ARTEMIS-2892) Replication stopped working after many failovers
[
https://issues.apache.org/jira/browse/ARTEMIS-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854799#comment-17854799
]
Clebert Suconic commented on ARTEMIS-2892:
--
I have extensively tried to reproduce this without any success.
if anyone find a way to reproduce this and send it to me, attach it here.. it
would get my full attention to make this solved.
> 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
>
>
> 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=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] [Commented] (ARTEMIS-4803) Lost the lock according to the monitor, notifying listeners
[
https://issues.apache.org/jira/browse/ARTEMIS-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854771#comment-17854771
]
Ayla commented on ARTEMIS-4803:
---
Attaching Master broker.xml file[^broker.xml]
> Lost the lock according to the monitor, notifying listeners
> ---
>
> Key: ARTEMIS-4803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4803
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
>Reporter: Ayla
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Capture.JPG, broker.xml
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> We just installed 2.33.0 on a Windows server using with shared file storage.
> We have the situation that we in get endless loop with the following entry in
> the artemis log file:
> {noformat}
> WARN [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] Lost
> the lock according to the monitor, notifying listeners{noformat}
> We noticed that if we changed the config file to local disk the problem does
> not happen.
> We are using {*}Windows based clustered file shared storage and it is SMB not
> NFS{*}.
> SMB configuration properties are as below:
> {noformat}
> PS C:\Windows\system32> Get-SmbClientConfiguration
> ConnectionCountPerRssNetworkInterface : 4
> DirectoryCacheEntriesMax : 16
> DirectoryCacheEntrySizeMax : 65536
> DirectoryCacheLifetime : 10
> DormantFileLimit : 1023
> EnableBandwidthThrottling : True
> EnableByteRangeLockingOnReadOnlyFiles : True
> EnableInsecureGuestLogons : False
> EnableLargeMtu : True
> EnableLoadBalanceScaleOut : True
> EnableMultiChannel : True
> EnableSecuritySignature : True
> ExtendedSessionTimeout : 1000
> FileInfoCacheEntriesMax : 64
> FileInfoCacheLifetime : 10
> FileNotFoundCacheEntriesMax : 128
> FileNotFoundCacheLifetime : 5
> KeepConn : 600
> MaxCmds : 50
> MaximumConnectionCountPerServer : 32
> OplocksDisabled : False
> RequireSecuritySignature : True
> SessionTimeout : 60
> UseOpportunisticLocking : True
> WindowSizeThreshold : 1{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] [Commented] (ARTEMIS-4816) Docker image echo's admin credentials during startup
[ https://issues.apache.org/jira/browse/ARTEMIS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854786#comment-17854786 ] ASF subversion and git services commented on ARTEMIS-4816: -- Commit b1c28d7bd416e614e6ec0504a6099f017a5e62a3 in activemq-artemis's branch refs/heads/main from Jeroen van Gorkum [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b1c28d7bd4 ] ARTEMIS-4816: Docker image echo's admin credentials during startup Signed-off-by: Jeroen van Gorkum > 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] [Created] (ARTEMIS-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
Timothy A. Bish created ARTEMIS-4817: Summary: 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.35.0, 2.34.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 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] [Updated] (ARTEMIS-4803) Lost the lock according to the monitor, notifying listeners
[
https://issues.apache.org/jira/browse/ARTEMIS-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ayla updated ARTEMIS-4803:
--
Attachment: broker.xml
> Lost the lock according to the monitor, notifying listeners
> ---
>
> Key: ARTEMIS-4803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4803
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
>Reporter: Ayla
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Capture.JPG, broker.xml
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> We just installed 2.33.0 on a Windows server using with shared file storage.
> We have the situation that we in get endless loop with the following entry in
> the artemis log file:
> {noformat}
> WARN [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] Lost
> the lock according to the monitor, notifying listeners{noformat}
> We noticed that if we changed the config file to local disk the problem does
> not happen.
> We are using {*}Windows based clustered file shared storage and it is SMB not
> NFS{*}.
> SMB configuration properties are as below:
> {noformat}
> PS C:\Windows\system32> Get-SmbClientConfiguration
> ConnectionCountPerRssNetworkInterface : 4
> DirectoryCacheEntriesMax : 16
> DirectoryCacheEntrySizeMax : 65536
> DirectoryCacheLifetime : 10
> DormantFileLimit : 1023
> EnableBandwidthThrottling : True
> EnableByteRangeLockingOnReadOnlyFiles : True
> EnableInsecureGuestLogons : False
> EnableLargeMtu : True
> EnableLoadBalanceScaleOut : True
> EnableMultiChannel : True
> EnableSecuritySignature : True
> ExtendedSessionTimeout : 1000
> FileInfoCacheEntriesMax : 64
> FileInfoCacheLifetime : 10
> FileNotFoundCacheEntriesMax : 128
> FileNotFoundCacheLifetime : 5
> KeepConn : 600
> MaxCmds : 50
> MaximumConnectionCountPerServer : 32
> OplocksDisabled : False
> RequireSecuritySignature : True
> SessionTimeout : 60
> UseOpportunisticLocking : True
> WindowSizeThreshold : 1{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] [Created] (ARTEMIS-4816) Docker image echo's admin credentials during startup
StandByStormMetaM created ARTEMIS-4816: -- Summary: 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 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] [Reopened] (ARTEMIS-4803) Lost the lock according to the monitor, notifying listeners
[ https://issues.apache.org/jira/browse/ARTEMIS-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ayla reopened ARTEMIS-4803: --- We enabled NFS on Windows server 2019 and created a share, used below mount commands: mount -o fileaccess=777 -o mtype=soft,noac -o timeout=50 -o retry=1 :/NFSTestFolder y: Attached you can find the broker.xml for the master node, however the Windows service keeps stopping with below errors: 2024-06-13 15:44:39,932 WARN [org.apache.activemq.artemis.core.server] AMQ222141: Node Manager can not open file y:\AMQ\data\journal\server.lock java.io.IOException: The system cannot find the path specified at java.io.WinNTFileSystem.createFileExclusively0(Native Method) ~[?:?] at java.io.WinNTFileSystem.createFileExclusively(WinNTFileSystem.java:645) ~[?:?] at java.io.File.createNewFile(File.java:1043) ~[?:?] at org.apache.activemq.artemis.core.server.impl.FileBasedNodeManager.setUpServerLockFile(FileBasedNodeManager.java:145) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.setUpServerLockFile(FileLockNodeManager.java:111) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.start(FileLockNodeManager.java:102) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:696) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:610) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:219) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:165) [artemis-cli-2.31.2.jar:2.31.2] at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?] at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:157) [artemis-boot.jar:2.31.2] at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:64) [artemis-boot.jar:2.31.2] 2024-06-13 15:44:39,948 ERROR [org.apache.activemq.artemis.core.server] AMQ224097: Failed to start server java.io.IOException: The system cannot find the path specified at java.io.WinNTFileSystem.createFileExclusively0(Native Method) ~[?:?] at java.io.WinNTFileSystem.createFileExclusively(WinNTFileSystem.java:645) ~[?:?] at java.io.File.createNewFile(File.java:1043) ~[?:?] at org.apache.activemq.artemis.core.server.impl.FileBasedNodeManager.setUpServerLockFile(FileBasedNodeManager.java:145) ~[artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.setUpServerLockFile(FileLockNodeManager.java:111) ~[artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.start(FileLockNodeManager.java:102) ~[artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:696) ~[artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:610) [artemis-server-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:219) [artemis-cli-2.31.2.jar:2.31.2] at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:165) [artemis-cli-2.31.2.jar:2.31.2] at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?] at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:157) [artemis-boot.jar:2.31.2] at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:64) [artemis-boot.jar:2.31.2] 2024-06-13 15:44:39,953 INFO [org.apache.activemq.artemis.core.server] AMQ221002: Apache ActiveMQ Artemis Message Broker version 2.31.2 [null] stopped, uptime 0.539 seconds > Lost the lock according to the monitor, notifying listeners > --- > > Key: ARTEMIS-4803 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4803 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >
[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] [Commented] (ARTEMIS-2965) Allow mirror to stop capture events and delete inner queue
[ https://issues.apache.org/jira/browse/ARTEMIS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854676#comment-17854676 ] Gary Tully commented on ARTEMIS-2965: - [~clebertsuconic] think of this in terms of config reload, such that there is no need for a restart. [~tabish] did some work on the reload of broker connections and there is support for adding mirrors, but the challenge of modifying or removing has not been covered. > Allow mirror to stop capture events and delete inner queue > -- > > Key: ARTEMIS-2965 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2965 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.16.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Critical > > When a mirror starts, the current events will not be cleared when > brokerConnection.stop() is called. > > We should support removing the Mirror manager, and deleting the queue upon > brokerConnection.stop(). > (or another method TBD that would determine the semantic to remove the SnF > queue and future generation on mirror). > Related comments: > [https://github.com/apache/activemq-artemis/pull/3316#discussion_r513491335] -- 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
