[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] [Resolved] (AMQ-7341) Admin web console does not work, when using a junction in the install path
[
https://issues.apache.org/jira/browse/AMQ-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved AMQ-7341.
-
Resolution: Information Provided
> Admin web console does not work, when using a junction in the install path
> --
>
> Key: AMQ-7341
> URL: https://issues.apache.org/jira/browse/AMQ-7341
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.15.10
> Environment: Windows server 2016/Windows 10
>Reporter: Jan Declercq
>Priority: Major
>
> In our environment ActiveMQ get's upgraded to the latest version every 6-12
> months.
> To make this easy we have this Directory structure:
> {code:none}
> c:\APP\ActiveMQ>dir
> Volume in drive C has no label.
> Directory of c:\APP\ActiveMQ
> 14/11/2019 16:58 .
> 14/11/2019 16:58 ..
> 14/11/2019 15:27 apache-activemq-5.15.10
> 15/03/2019 08:04 apache-activemq-5.15.9
> 14/11/2019 15:52 Current [c:\APP\ActiveMQ\apache-activemq-5.15.9]
> 0 File(s) 0 bytes
> 5 Dir(s) 216.928.550.912 bytes free
> {code}
>
> When the new version (5.15.10) is all tested,configured and ready, we stop
> the old (5.15.9) and replace the junction.
> code executed:
>
> {code:none}
> net stop activemq
> rmdir Current
> mklink /j Current c:\app\ActiveMQ\apache-activemq-5.15.10
> net start activemq
> {code}
> With version 5.15.10 the web console no longer works when started from a
> junction..
> This worked perfectly in previous versions.
> Workaround: delete the junction, rename versioned folder to current..
>
> Steps to reproduce:
>
> {code:java}
> download:
> https://apache.cu.be//activemq/5.15.10/apache-activemq-5.15.10-bin.zip
> unzip to c:\app\activemq\
> mklink /j c:\app\activemq\current c:\app\activemq\apache-activemq-5.15.10
> c:\app\activemq\current\bin\win64\InstallService.bat
> net start activemq
> Surf to http://localhost:8161 => broken
> {code}
>
> The error in the log file is:
> {code:none}
> 2019-11-14 15:49:41,909 | WARN | Failed startup of context
> o.e.j.w.WebAppContext@5f878b41{ActiveMQ
> Console,/admin,file:///C:/APP/ActiveMQ/Current/webapps/admin/,UNAVAILABLE} |
> org.eclipse.jetty.webapp.WebAppContext | WrapperSimpleAppMain2019-11-14
> 15:49:41,909 | WARN | Failed startup of context
> o.e.j.w.WebAppContext@5f878b41{ActiveMQ
> Console,/admin,file:///C:/APP/ActiveMQ/Current/webapps/admin/,UNAVAILABLE} |
> org.eclipse.jetty.webapp.WebAppContext |
> WrapperSimpleAppMainorg.springframework.beans.factory.BeanDefinitionStoreException:
> IOException parsing XML document from ServletContext resource
> [/WEB-INF/webconsole-embedded.xml]; nested exception is
> java.io.FileNotFoundException: Could not open ServletContext resource
> [/WEB-INF/webconsole-embedded.xml] at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:344)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:217)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:188)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:125)[spring-web-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:94)[spring-web-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:129)[spring-context-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:614)[spring-context-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:514)[spring-context-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.apache.activemq.web.WebConsoleStarter.createWebapplicationContext(WebConsoleStarter.java:71)
> at
>
[jira] [Comment Edited] (AMQ-7341) Admin web console does not work, when using a junction in the install path
[
https://issues.apache.org/jira/browse/AMQ-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17271780#comment-17271780
]
Justin Bertram edited comment on AMQ-7341 at 6/18/24 9:25 PM:
--
This is not a bug per se. This new version of the broker uses a new version of
Jetty which started to differentiate between regular files and the symbolic
links and imposes a restriction on it. There is a way to fix this issue in
{{jetty.xml}}.
{code:xml}
...
...{code}
was (Author: mikema):
this is not an activemq bug per se. this new version of activemq uses a new
version of Jetty, which started to make a difference between regular file and
the symbolic link/junction, and imposes a restriction on it. there is a way to
fix this issue in jetty.xml.
...
> Admin web console does not work, when using a junction in the install path
> --
>
> Key: AMQ-7341
> URL: https://issues.apache.org/jira/browse/AMQ-7341
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.15.10
> Environment: Windows server 2016/Windows 10
>Reporter: Jan Declercq
>Priority: Major
>
> In our environment ActiveMQ get's upgraded to the latest version every 6-12
> months.
> To make this easy we have this Directory structure:
> {code:none}
> c:\APP\ActiveMQ>dir
> Volume in drive C has no label.
> Directory of c:\APP\ActiveMQ
> 14/11/2019 16:58 .
> 14/11/2019 16:58 ..
> 14/11/2019 15:27 apache-activemq-5.15.10
> 15/03/2019 08:04 apache-activemq-5.15.9
> 14/11/2019 15:52 Current [c:\APP\ActiveMQ\apache-activemq-5.15.9]
> 0 File(s) 0 bytes
> 5 Dir(s) 216.928.550.912 bytes free
> {code}
>
> When the new version (5.15.10) is all tested,configured and ready, we stop
> the old (5.15.9) and replace the junction.
> code executed:
>
> {code:none}
> net stop activemq
> rmdir Current
> mklink /j Current c:\app\ActiveMQ\apache-activemq-5.15.10
> net start activemq
> {code}
> With version 5.15.10 the web console no longer works when started from a
> junction..
> This worked perfectly in previous versions.
> Workaround: delete the junction, rename versioned folder to current..
>
> Steps to reproduce:
>
> {code:java}
> download:
> https://apache.cu.be//activemq/5.15.10/apache-activemq-5.15.10-bin.zip
> unzip to c:\app\activemq\
> mklink /j c:\app\activemq\current c:\app\activemq\apache-activemq-5.15.10
> c:\app\activemq\current\bin\win64\InstallService.bat
> net start activemq
> Surf to http://localhost:8161 => broken
> {code}
>
> The error in the log file is:
> {code:none}
> 2019-11-14 15:49:41,909 | WARN | Failed startup of context
> o.e.j.w.WebAppContext@5f878b41{ActiveMQ
> Console,/admin,file:///C:/APP/ActiveMQ/Current/webapps/admin/,UNAVAILABLE} |
> org.eclipse.jetty.webapp.WebAppContext | WrapperSimpleAppMain2019-11-14
> 15:49:41,909 | WARN | Failed startup of context
> o.e.j.w.WebAppContext@5f878b41{ActiveMQ
> Console,/admin,file:///C:/APP/ActiveMQ/Current/webapps/admin/,UNAVAILABLE} |
> org.eclipse.jetty.webapp.WebAppContext |
> WrapperSimpleAppMainorg.springframework.beans.factory.BeanDefinitionStoreException:
> IOException parsing XML document from ServletContext resource
> [/WEB-INF/webconsole-embedded.xml]; nested exception is
> java.io.FileNotFoundException: Could not open ServletContext resource
> [/WEB-INF/webconsole-embedded.xml] at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:344)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:217)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:188)[spring-beans-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:125)[spring-web-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
> org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:94)[spring-web-4.3.24.RELEASE.jar:4.3.24.RELEASE]
> at
>
[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] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge is paused while messages being produced to target node.
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Affects Version/s: 2.35.0
> CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge
> is paused while messages being produced to target node.
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0, 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
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-4794) CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge is paused while messages being produced to target node.
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Summary: CoreBridge: Duplicate message when bridge is stopped/Lost message
when bridge is paused while messages being produced to target node. (was:
CoreBridge: Duplicate message when bridge is stopped while messages being
produced to target node)
> CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge
> is paused while messages being produced to target node.
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
[
https://issues.apache.org/jira/browse/ARTEMIS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4821:
-
Description:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test [^MessageCount235Test.java] case
*testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
attempt other scenario which succeed
I link also [^MessageCount230Test.java] for version 2.30 (it is another file
because due to renaming of master/slave, SimpleString and migration to junit5,
code needs to be adapt), all scenario are succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I face the issue only when using bridge, issue might be due to async
acknowledgement
was:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test [^MessageCount235Test.java] case
*testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
attempt other scenario which succeed
I link also [^MessageCount230Test.java] for version 2.30 (it is another file
because due to renaming of master/slave, SimpleString and migration to junit5,
code needs to be adapt), all scenario are succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
> Message count is not correct in case of failover while a bridge is open on a
> paging address
> ---
>
> Key: ARTEMIS-4821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: MessageCount230Test.java, MessageCount235Test.java
>
>
> After upgrading from 2.30 to 2.34 one of my test case is failling
> {{QueueImpl::getMessageCount()}} does not returns what was expected
> See attached Test [^MessageCount235Test.java] case
> *testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
> attempt other scenario which succeed
> I link also [^MessageCount230Test.java] for version 2.30 (it is another file
> because due to renaming of master/slave, SimpleString and migration to
> junit5, code needs to be adapt), all scenario are succeed
>
> {code:java}
> Topology: Simulating DC1 (1 primary + backup pair)
> Simulating DC2 1 single primary node
> 1. Produce messages on dc1Primary1
> 2. Start a bridge from dc1Primary1 to dc2Primary1
> 3. Stop dc1Primary1 while transfer has started but not finished
> 4. dc1Backup1 become alive
> 5. Start a bridge from dc1Backup1 to dc2Primary1
> 6. dc2Primary1 has received all messages produced originally
> 7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
> Notes: if address is not paging, there is no issue
> {code}
> After investigation it happen only when address is paging.
> Also as I face the issue only when using bridge, issue might be due to async
> acknowledgement
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
[
https://issues.apache.org/jira/browse/ARTEMIS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4821:
-
Description:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test [^MessageCount235Test.java] case
*testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
attempt other scenario which succeed
I link also [^MessageCount230Test.java] for version 2.30 (it is another file
because due to renaming of master/slave, SimpleString and migration to junit5,
code needs to be adapt), all scenario are succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
was:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test [^MessageCount235Test.java] case
*testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
attempt other scenario which succeed
I link also [^MessageCount230Test.java] for version 2.30 (it is another file
because due to renaming of master/slave, SimpleString and migration to junit5,
code need to be adapt), all scenario are succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
> Message count is not correct in case of failover while a bridge is open on a
> paging address
> ---
>
> Key: ARTEMIS-4821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: MessageCount230Test.java, MessageCount235Test.java
>
>
> After upgrading from 2.30 to 2.34 one of my test case is failling
> {{QueueImpl::getMessageCount()}} does not returns what was expected
> See attached Test [^MessageCount235Test.java] case
> *testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
> attempt other scenario which succeed
> I link also [^MessageCount230Test.java] for version 2.30 (it is another file
> because due to renaming of master/slave, SimpleString and migration to
> junit5, code needs to be adapt), all scenario are succeed
>
> {code:java}
> Topology: Simulating DC1 (1 primary + backup pair)
> Simulating DC2 1 single primary node
> 1. Produce messages on dc1Primary1
> 2. Start a bridge from dc1Primary1 to dc2Primary1
> 3. Stop dc1Primary1 while transfer has started but not finished
> 4. dc1Backup1 become alive
> 5. Start a bridge from dc1Backup1 to dc2Primary1
> 6. dc2Primary1 has received all messages produced originally
> 7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
> Notes: if address is not paging, there is no issue
> {code}
> After investigation it happen only when address is paging.
> Also as I can reproduce only when using bridge it might be due to async
> acknowledgement
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
[
https://issues.apache.org/jira/browse/ARTEMIS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4821:
-
Description:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test [^MessageCount235Test.java] case
*testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
attempt other scenario which succeed
I link also [^MessageCount230Test.java] for version 2.30 (it is another file
because due to renaming of master/slave, SimpleString and migration to junit5,
code need to be adapt), all scenario are succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
was:
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test case *testMessageCount_whenFailoverHappenWhileBridgeIsOpen*
which is failing, I attempt other scenario which succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
> Message count is not correct in case of failover while a bridge is open on a
> paging address
> ---
>
> Key: ARTEMIS-4821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: MessageCount230Test.java, MessageCount235Test.java
>
>
> After upgrading from 2.30 to 2.34 one of my test case is failling
> {{QueueImpl::getMessageCount()}} does not returns what was expected
> See attached Test [^MessageCount235Test.java] case
> *testMessageCount_whenFailoverHappenWhileBridgeIsOpen* which is failing, I
> attempt other scenario which succeed
> I link also [^MessageCount230Test.java] for version 2.30 (it is another file
> because due to renaming of master/slave, SimpleString and migration to
> junit5, code need to be adapt), all scenario are succeed
>
> {code:java}
> Topology: Simulating DC1 (1 primary + backup pair)
> Simulating DC2 1 single primary node
> 1. Produce messages on dc1Primary1
> 2. Start a bridge from dc1Primary1 to dc2Primary1
> 3. Stop dc1Primary1 while transfer has started but not finished
> 4. dc1Backup1 become alive
> 5. Start a bridge from dc1Backup1 to dc2Primary1
> 6. dc2Primary1 has received all messages produced originally
> 7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
> Notes: if address is not paging, there is no issue
> {code}
> After investigation it happen only when address is paging.
> Also as I can reproduce only when using bridge it might be due to async
> acknowledgement
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
[
https://issues.apache.org/jira/browse/ARTEMIS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4821:
-
Attachment: MessageCount235Test.java
> Message count is not correct in case of failover while a bridge is open on a
> paging address
> ---
>
> Key: ARTEMIS-4821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: MessageCount230Test.java, MessageCount235Test.java
>
>
> After upgrading from 2.30 to 2.34 one of my test case is failling
> {{QueueImpl::getMessageCount()}} does not returns what was expected
> See attached Test case *testMessageCount_whenFailoverHappenWhileBridgeIsOpen*
> which is failing, I attempt other scenario which succeed
>
> {code:java}
> Topology: Simulating DC1 (1 primary + backup pair)
> Simulating DC2 1 single primary node
> 1. Produce messages on dc1Primary1
> 2. Start a bridge from dc1Primary1 to dc2Primary1
> 3. Stop dc1Primary1 while transfer has started but not finished
> 4. dc1Backup1 become alive
> 5. Start a bridge from dc1Backup1 to dc2Primary1
> 6. dc2Primary1 has received all messages produced originally
> 7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
> Notes: if address is not paging, there is no issue
> {code}
> After investigation it happen only when address is paging.
> Also as I can reproduce only when using bridge it might be due to async
> acknowledgement
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
[
https://issues.apache.org/jira/browse/ARTEMIS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4821:
-
Attachment: MessageCount230Test.java
> Message count is not correct in case of failover while a bridge is open on a
> paging address
> ---
>
> Key: ARTEMIS-4821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Major
> Attachments: MessageCount230Test.java
>
>
> After upgrading from 2.30 to 2.34 one of my test case is failling
> {{QueueImpl::getMessageCount()}} does not returns what was expected
> See attached Test case *testMessageCount_whenFailoverHappenWhileBridgeIsOpen*
> which is failing, I attempt other scenario which succeed
>
> {code:java}
> Topology: Simulating DC1 (1 primary + backup pair)
> Simulating DC2 1 single primary node
> 1. Produce messages on dc1Primary1
> 2. Start a bridge from dc1Primary1 to dc2Primary1
> 3. Stop dc1Primary1 while transfer has started but not finished
> 4. dc1Backup1 become alive
> 5. Start a bridge from dc1Backup1 to dc2Primary1
> 6. dc2Primary1 has received all messages produced originally
> 7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
> Notes: if address is not paging, there is no issue
> {code}
> After investigation it happen only when address is paging.
> Also as I can reproduce only when using bridge it might be due to async
> acknowledgement
--
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-4821) Message count is not correct in case of failover while a bridge is open on a paging address
nmeylan created ARTEMIS-4821:
Summary: Message count is not correct in case of failover while a
bridge is open on a paging address
Key: ARTEMIS-4821
URL: https://issues.apache.org/jira/browse/ARTEMIS-4821
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.35.0
Reporter: nmeylan
After upgrading from 2.30 to 2.34 one of my test case is failling
{{QueueImpl::getMessageCount()}} does not returns what was expected
See attached Test case *testMessageCount_whenFailoverHappenWhileBridgeIsOpen*
which is failing, I attempt other scenario which succeed
{code:java}
Topology: Simulating DC1 (1 primary + backup pair)
Simulating DC2 1 single primary node
1. Produce messages on dc1Primary1
2. Start a bridge from dc1Primary1 to dc2Primary1
3. Stop dc1Primary1 while transfer has started but not finished
4. dc1Backup1 become alive
5. Start a bridge from dc1Backup1 to dc2Primary1
6. dc2Primary1 has received all messages produced originally
7. Expected: messageCount on dc1Backup1 to be equal to 0, but actual is > 0
Notes: if address is not paging, there is no issue
{code}
After investigation it happen only when address is paging.
Also as I can reproduce only when using bridge it might be due to async
acknowledgement
--
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-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino resolved ARTEMIS-4818. -- Fix Version/s: 2.36.0 Resolution: Fixed > 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 > Fix For: 2.36.0 > > 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] [Commented] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855908#comment-17855908 ] ASF subversion and git services commented on ARTEMIS-4818: -- Commit e5e95f4a182d442bd5c1b4c64906c39fc2ae662f in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e5e95f4a18 ] ARTEMIS-4818 Support classes with .class in the package > 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=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] [Commented] (ARTEMIS-4818) Improve support for multiple broker plugins from broker properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855863#comment-17855863 ] ASF subversion and git services commented on ARTEMIS-4818: -- Commit a10694f202583e145e7d06c27488814d8b28b762 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a10694f202 ] ARTEMIS-4818 Improve support for multiple broker plugins from broker properties > 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-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
