[jira] [Work logged] (AMQ-7426) Upgrade to log4j2
[
https://issues.apache.org/jira/browse/AMQ-7426?focusedWorklogId=697072&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-697072
]
ASF GitHub Bot logged work on AMQ-7426:
---
Author: ASF GitHub Bot
Created on: 16/Dec/21 05:17
Start Date: 16/Dec/21 05:17
Worklog Time Spent: 10m
Work Description: lucastetreault commented on a change in pull request
#662:
URL: https://github.com/apache/activemq/pull/662#discussion_r770230966
##
File path: assembly/pom.xml
##
@@ -431,16 +435,6 @@
json-simple
${json-simple-version}
-
Review comment:
Good to see some old defunct stuff cleaned up at the same time!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 697072)
Time Spent: 1h 20m (was: 1h 10m)
> Upgrade to log4j2
> -
>
> Key: AMQ-7426
> URL: https://issues.apache.org/jira/browse/AMQ-7426
> Project: ActiveMQ
> Issue Type: Task
> Components: Broker
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (AMQ-8437) Destination policy not applied when multiple policies with wildcard exist
Rohan Chauhan created AMQ-8437:
--
Summary: Destination policy not applied when multiple policies
with wildcard exist
Key: AMQ-8437
URL: https://issues.apache.org/jira/browse/AMQ-8437
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.16.3, 5.16.0
Environment: centos 7; activeMQ version 5.16.3
Reporter: Rohan Chauhan
I am setting up deadLetterPolicies for undelivered messages but the
individualDeadLetterStrategy doesn't get applied if I use a wildcard. I was
expecting creation of DLQ.app/events/foo to be created, for a queue named
app/events/foo, and undelivered messages moved into it. Unfortunately the
individual DLQ is not created and undelivered messages end up in default DLQ
i.e. ActiveMQ.DLQ.
{code:java}
{code}
The individualDeadLetterStrategy works fine when I don't use wildcard.
{code:java}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (AMQ-7370) log4j 1.2 version used by AMQ 5.15.10 / 5.15.11 is vulnerable to CVE-2019-17571
[ https://issues.apache.org/jira/browse/AMQ-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460247#comment-17460247 ] Justin Bertram edited comment on AMQ-7370 at 12/15/21, 9:02 PM: [~stappe], no. The move to Log4j 2.x was moved to 5.17.0 which has not yet been released. See AMQ-7426. was (Author: jbertram): [~stappe], no. The move to Log4j 2.x was moved to 5.17.0 which has not yet been released. > log4j 1.2 version used by AMQ 5.15.10 / 5.15.11 is vulnerable to > CVE-2019-17571 > --- > > Key: AMQ-7370 > URL: https://issues.apache.org/jira/browse/AMQ-7370 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.10, 5.15.11 >Reporter: Abhijit Rajwade >Assignee: Jean-Baptiste Onofré >Priority: Major > > Sonatype Nexus auditor is reporting following log4j related security issue on > Apache ActiveMQ 5.15.10 and 5.15.11. Recommendation is to use > org.apache.logging.log4j:log4j-core version(s) 2.8.2 and above. Can you > please check if Apache ActiveMQ is vulnerable and if so upgrade based on the > recommendation? > Description from CVE > Included in Log4j 1.2 is a SocketServer class that is vulnerable to > deserialization of untrusted data which can be exploited to remotely execute > arbitrary code when combined with a deserialization gadget when listening to > untrusted network traffic for log data. This affects Log4j versions up to 1.2 > up to 1.2.17. > Explanation > The log4j:log4j package is vulnerable to Remote Code Execution (RCE) due > to Deserialization of Untrusted Data. The configureHierarchy and > genericHierarchy methods in SocketServer.class do not verify if the file at a > given file path contains any untrusted objects prior to deserializing them. A > remote attacker can exploit this vulnerability by providing a path to crafted > files, which result in arbitrary code execution when deserialized. > NOTE: Starting with version(s) 2.x, log4j:log4j was relocated to > org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists > in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to > but excluding 2.8.2. > Detection > The application is vulnerable by using this component. > Recommendation > Starting with version(s) 2.x, log4j:log4j was relocated to > org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists > in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to > but excluding 2.8.2. Therefore, it is recommended to upgrade to > org.apache.logging.log4j:log4j-core version(s) 2.8.2 and above. For > log4j:log4j 1.x versions however, a fix does not exist. > Root Cause > activemq-all-5.15.10.jar <= org/apache/log4j/net/SocketServer.class : (,) > Advisories > Project: https://issues.apache.org/jira/browse/LOG4J2-1863 > Project: https://lists.apache.org/thread.html/84cc4266238e057b95eb95d… > Third Party: https://bugzilla.redhat.com/show_bug.cgi?id=1785616 > CVSS Details > Sonatype CVSS 3: 9.8 > CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-7370) log4j 1.2 version used by AMQ 5.15.10 / 5.15.11 is vulnerable to CVE-2019-17571
[ https://issues.apache.org/jira/browse/AMQ-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460247#comment-17460247 ] Justin Bertram commented on AMQ-7370: - [~stappe], no. The move to Log4j 2.x was moved to 5.17.0 which has not yet been released. > log4j 1.2 version used by AMQ 5.15.10 / 5.15.11 is vulnerable to > CVE-2019-17571 > --- > > Key: AMQ-7370 > URL: https://issues.apache.org/jira/browse/AMQ-7370 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.10, 5.15.11 >Reporter: Abhijit Rajwade >Assignee: Jean-Baptiste Onofré >Priority: Major > > Sonatype Nexus auditor is reporting following log4j related security issue on > Apache ActiveMQ 5.15.10 and 5.15.11. Recommendation is to use > org.apache.logging.log4j:log4j-core version(s) 2.8.2 and above. Can you > please check if Apache ActiveMQ is vulnerable and if so upgrade based on the > recommendation? > Description from CVE > Included in Log4j 1.2 is a SocketServer class that is vulnerable to > deserialization of untrusted data which can be exploited to remotely execute > arbitrary code when combined with a deserialization gadget when listening to > untrusted network traffic for log data. This affects Log4j versions up to 1.2 > up to 1.2.17. > Explanation > The log4j:log4j package is vulnerable to Remote Code Execution (RCE) due > to Deserialization of Untrusted Data. The configureHierarchy and > genericHierarchy methods in SocketServer.class do not verify if the file at a > given file path contains any untrusted objects prior to deserializing them. A > remote attacker can exploit this vulnerability by providing a path to crafted > files, which result in arbitrary code execution when deserialized. > NOTE: Starting with version(s) 2.x, log4j:log4j was relocated to > org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists > in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to > but excluding 2.8.2. > Detection > The application is vulnerable by using this component. > Recommendation > Starting with version(s) 2.x, log4j:log4j was relocated to > org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists > in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to > but excluding 2.8.2. Therefore, it is recommended to upgrade to > org.apache.logging.log4j:log4j-core version(s) 2.8.2 and above. For > log4j:log4j 1.x versions however, a fix does not exist. > Root Cause > activemq-all-5.15.10.jar <= org/apache/log4j/net/SocketServer.class : (,) > Advisories > Project: https://issues.apache.org/jira/browse/LOG4J2-1863 > Project: https://lists.apache.org/thread.html/84cc4266238e057b95eb95d… > Third Party: https://bugzilla.redhat.com/show_bug.cgi?id=1785616 > CVSS Details > Sonatype CVSS 3: 9.8 > CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3587) After upgrade: AMQ224107: The Critical Analyzer detected slow paths on the broker.
[ https://issues.apache.org/jira/browse/ARTEMIS-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460123#comment-17460123 ] Clebert Suconic commented on ARTEMIS-3587: -- 2.20.0 is under vote, with this issue fixed. You should be able to pick up the candidate release already and provide some feedback please. > After upgrade: AMQ224107: The Critical Analyzer detected slow paths on the > broker. > -- > > Key: ARTEMIS-3587 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3587 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Sebastian T >Priority: Major > Labels: performance > Fix For: 2.20.0 > > Attachments: log_with_stacktrace.log > > Time Spent: 10m > Remaining Estimate: 0h > > After upgrading from Artemis 2.16.0 to 2.19.0 we now receive the following > message a few times a day: > 2021-11-05 05:32:53.641 WARN 3850 --- [eduled-threads)] > o.a.a.a.u.c.CriticalMeasure : Component > org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 4 > 2021-11-05 05:32:53.642 INFO 3850 --- [eduled-threads)] o.a.a.a.c.server >: AMQ224107: The Critical Analyzer detected slow paths on > the broker. It is recommended that you enable trace logs on > org.apache.activemq.artemis.utils.critical while you troubleshoot this issue. > You should disable the trace logs when you have finished troubleshooting. > This message is also logged via ActiveMQServerCriticalPlugin#criticalFailure > however the javadoc says: "This will be called before the broker is stopped." > The broker however is not stopped. So I think the javadoc and the behaviour > of the callback are not in line anymore too. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3083) Set a default producer-window-size on cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-3083: - Description: The current producer-window-size configuration for cluster connection is -1 ie unbounded: it means that in case of an intermittent slow network or scarce CPU resource on the receiving cluster node (due to GC activity, OOM or other reasons) both brokers risk to go OOM: * the sender one because of the resend cache on the channel of the cluster connection (still present because of confirmation window size defaulted to 1 MB): unbounded granted credits means that it could grow unbounded while containing the clustered packets awaiting to get response or confirmation from the other node (that could be busy/overloaded and unable to answer anything back) * the receiver one due to the Actor abstraction on the cluster connection: the sender would try to send as much packets it can, regardless the ability of the receiver to consume them, that would accumulated on the actor mailbox (that's unbounded) instead of the TCP buffer (that's bounded) was: The current producer-window-size configuration for cluster connection is -1 ie unbounded: it means that in case of an intermittent slow network or scarce CPU resource on the receiving cluster node (due to GC activity, OOM or other reasons) both brokers risk to go OOM: * the sender one because of the resend cache on the channel of the cluster connection (still present because of confirmation window size defaulted to 1 MB): unbounded granted credits means that it could grow unbounded while containing the clustered packets awaiting to get response or confirmation from the other node (that could be busy/overloaded and unable to answer anything back) * the receiver one due to the Actor abstraction on the cluster connection: the sender would try to send as much packets it can, regardless the ability of the receiver to consume them > Set a default producer-window-size on cluster connection > > > Key: ARTEMIS-3083 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3083 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > The current producer-window-size configuration for cluster connection is -1 > ie unbounded: it means that in case of an intermittent slow network or scarce > CPU resource on the receiving cluster node (due to GC activity, OOM or other > reasons) both brokers risk to go OOM: > * the sender one because of the resend cache on the channel of the cluster > connection (still present because of confirmation window size defaulted to 1 > MB): unbounded granted credits means that it could grow unbounded while > containing the clustered packets awaiting to get response or confirmation > from the other node (that could be busy/overloaded and unable to answer > anything back) > * the receiver one due to the Actor abstraction on the cluster connection: > the sender would try to send as much packets it can, regardless the ability > of the receiver to consume them, that would accumulated on the actor mailbox > (that's unbounded) instead of the TCP buffer (that's bounded) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3083) Set a default producer-window-size on cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-3083: - Description: The current producer-window-size configuration for cluster connection is -1 ie unbounded: it means that in case of an intermittent slow network or scarce CPU resource on the receiving cluster node (due to GC activity, OOM or other reasons) both brokers risk to go OOM: * the sender one because of the resend cache on the channel of the cluster connection (still present because of confirmation window size defaulted to 1 MB): unbounded granted credits means that it could grow unbounded while containing the clustered packets awaiting to get response or confirmation from the other node (that could be busy/overloaded and unable to answer anything back) * the receiver one due to the Actor abstraction on the cluster connection: the sender would try to send as much packets it can, regardless the ability of the receiver to consume them was: The current producer-window-size configuration for cluster connection is -1 ie unbounded: it means that in case of an intermittent slow network or scarce CPU resource on the receiving cluster node (due to GC activity, OOM or other reasons) both brokers risk to go OOM: * the sender one because of the resend cache on the channel of the cluster connection: having unbounded granted credits means that it could grow unbounded while containing the clustered packets awaiting to get response * the receiver one because of the Actor abstraction on the cluster connection: because the sender would try to send as much packets it can, regardless the ability of the receiver to consume them > Set a default producer-window-size on cluster connection > > > Key: ARTEMIS-3083 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3083 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > The current producer-window-size configuration for cluster connection is -1 > ie unbounded: it means that in case of an intermittent slow network or scarce > CPU resource on the receiving cluster node (due to GC activity, OOM or other > reasons) both brokers risk to go OOM: > * the sender one because of the resend cache on the channel of the cluster > connection (still present because of confirmation window size defaulted to 1 > MB): unbounded granted credits means that it could grow unbounded while > containing the clustered packets awaiting to get response or confirmation > from the other node (that could be busy/overloaded and unable to answer > anything back) > * the receiver one due to the Actor abstraction on the cluster connection: > the sender would try to send as much packets it can, regardless the ability > of the receiver to consume them -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel ] Clebert Suconic updated ARTEMIS-2965: - Fix Version/s: 2.21.0 (was: 2.20.0) > 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 > Fix For: 2.21.0 > > > 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.1#820001)
[jira] [Updated] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[
https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated ARTEMIS-2618:
-
Fix Version/s: 2.21.0
(was: 2.20.0)
> Improve Handling of Shutdown on critical I/O Error
> --
>
> Key: ARTEMIS-2618
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2618
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.11.0
>Reporter: Rico Neubauer
>Priority: Major
> Fix For: 2.21.0
>
> Attachments: Improve-Handling-of-Shutdown-on-critic.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Would like to request an improvement in the handling of critical I/O errors
> on opening journal files.
> If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to
> open a journal file, the whole server shuts down with {{@Message(id = 222010,
> value = "Critical IO Error, shutting down the server. file=1, message=0"}}.
> We have seen this in the wild, where a backup-software locked the file for a
> short time while journal was about getting opened, resulting in the shutdown.
> Proposed improvement would be to have a short-running retry for opening the
> journal files and only fail fatally if error persists.
> Will attach a proposal patch. Can also create a PR if you accept.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3575) Wrong address size estimation on broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3575. > Wrong address size estimation on broker restart > --- > > Key: ARTEMIS-3575 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3575 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > Using the GUI in the console: > * Create a new multicast address named "mytest" > * Select the address and create a durable multicast queue named "mytest" > * Use the artemis CLI to produce messages. For example like this: > artemis producer --user admin --password admin --url tcp://localhost:61616 > --destination topic://mytest --message-count 1000 --message-size 40960 > --threads 4 > Note the reported address memory used in the console: in the example above it > is 160.26MB > * restart the broker > * the reported address memory is now below 1 MB > The error seems due to the paging store owner that's not correctly set on the > message while loading it, preventing its memory estimation to be accounted > into the address size. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3535.
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: arne anka
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Attachments: artemis-rest-2.19.0.war, broken_message.png, broker.xml,
> limited.jpg, rest.messaging.config.file.xml, test.xml, unlimited.jpg, web.xml
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3555) Invalid Journal Update Record could break compacting
[ https://issues.apache.org/jira/browse/ARTEMIS-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3555. Fix Version/s: 2.20.0 Resolution: Fixed > Invalid Journal Update Record could break compacting > > > Key: ARTEMIS-3555 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3555 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > I had a bug in an older version of Artemis, and the newer broker would not be > able to open compacting, leading to this exception: > AMQ142032: Error reading journal file: java.lang.IllegalArgumentException: > Keys and values must be >= 0 > at > org.apache.activemq.artemis.utils.collections.ConcurrentLongHashSet.checkBiggerEqualZero(ConcurrentLongHashSet.java:428) > [artemis-commons-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.utils.collections.ConcurrentLongHashSet.contains(ConcurrentLongHashSet.java:119) > [artemis-commons-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.containsRecord(AbstractJournalUpdateTask.java:247) > [artemis-journal-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.core.journal.impl.JournalCompactor.onReadUpdateRecordTX(JournalCompactor.java:484) > [artemis-journal-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:849) > [artemis-journal-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1868) > [artemis-journal-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.cli.commands.tools.journal.CompactJournal.compactJournal(CompactJournal.java:79) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.cli.commands.tools.journal.CompactJournal.compactJournals(CompactJournal.java:47) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.cli.commands.tools.journal.CompactJournal.execute(CompactJournal.java:38) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:157) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:105) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:132) > [artemis-cli-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) [java.base:] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [java.base:] > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java.base:] > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > [java.base:] > at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:134) > [artemis-boot.jar:2.20.0-SNAPSHOT] > at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:50) > [artemis-boot.jar:2.20.0-SNAPSHOT] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3363) using parameter minLargeMessage on cluster connections results in stack traces
[
https://issues.apache.org/jira/browse/ARTEMIS-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3363.
> using parameter minLargeMessage on cluster connections results in stack traces
> --
>
> Key: ARTEMIS-3363
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3363
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In an attempt to set the large message boundary on cluster connections, I
> added the parameter {{minLargeMessageSize=100}} to the callback url.
> This showed a stack trace error when it was used. The stack traces are
> repeated hundreds of times per second and seemed continuous.
> Looking at the stack traces, there actually seems to be 2 different stack
> traces that are alternating. A copy of each is listed below.
> Note that decimal 1850499442 = hex 6E4C6172 = ascii "{{nLar}}"; which are 4
> characters that also appear in the parameter name {{minLargeMessageSize}}.
> {noformat}
> jun. 22, 2021 11:15:46 P.M.
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl
> fail
> WARN: AMQ212037: Connection failure to hostname3/127.0.0.1:61616 has been
> detected: java.lang.IndexOutOfBoundsException: Error reading in simpleString,
> length
> =1850499442 is greater than readableBytes=36 [code=GENERIC_EXCEPTION]
> jun. 22, 2021 11:15:46 P.M.
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl
> bufferReceived
> ERROR: AMQ214013: Failed to decode packet
> java.lang.IndexOutOfBoundsException: Error reading in simpleString,
> length=1850499442 is greater than readableBytes=36
> at
> org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:185)
> at
> org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:173)
> at
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readStringInternal(ChannelBufferWrapper.java:113)
> at
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableString(ChannelBufferWrapper.java:88)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.ClusterTopologyChangeMessage_V3.decodeRest(ClusterTopologyChangeMessage_V3.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.PacketImpl.decode(PacketImpl.java:364)
> at
> org.apache.activemq.artemis.core.protocol.ServerPacketDecoder.slowPathDecode(ServerPacketDecoder.java:277)
> at
> org.apache.activemq.artemis.core.protocol.ServerPacketDecoder.decode(ServerPacketDecoder.java:149)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:377)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1230)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
[jira] [Closed] (ARTEMIS-3495) Backup cluster controller connection loop after failover
[ https://issues.apache.org/jira/browse/ARTEMIS-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3495. > Backup cluster controller connection loop after failover > > > Key: ARTEMIS-3495 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3495 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.18.0 >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Cluster controllers use the server locator relative to the default cluster > connection to monitor the nodes of the cluster. In a cluster with 2 nodes, a > live and a backup, the server locator of the cluster controller of the backup > node connects to the live node and after the live crash it connects to the > backup node creating a connection loop. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3530) Space in role list breaks user listing
[
https://issues.apache.org/jira/browse/ARTEMIS-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3530.
> Space in role list breaks user listing
> --
>
> Key: ARTEMIS-3530
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3530
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If we have a {{artemis-roles.properties}} like so:
> {code:java}
> role1 = user1, user2
> role2 = user2{code}
> however, when I display the list of users through the cli I get:
> {code:java}
> $ ./artemis user list
> Connection brokerURL = tcp://localhost:61616
> --- "user"(roles) ---
> "user2"(role2)
> "user1"(role1){code}
> {{user2}} should have the {{role1}} role as well.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-1925) Allow message redistribution even with OFF message-load-balancing semantics
[
https://issues.apache.org/jira/browse/ARTEMIS-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-1925.
> Allow message redistribution even with OFF message-load-balancing semantics
> ---
>
> Key: ARTEMIS-1925
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1925
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> Currently if the {{message-load-balancing}} is {{STRICT}} or {{OFF}} then
> message redistribution is disabled. Message redistribution should be
> controlled only by the {{redistribtion-delay}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3594) Broker balancer - allow a key transformer for a local-target-filter
[ https://issues.apache.org/jira/browse/ARTEMIS-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3594. > Broker balancer - allow a key transformer for a local-target-filter > --- > > Key: ARTEMIS-3594 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3594 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: balancer >Affects Versions: 2.19.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add support of a CONSISTENT_HASH_MODULO key transformer that can be used for > jms durable subs in a cluster. > Using a consistent hash on the clientID, that can be transformed into an int > < numBrokers such that each value is mapped to a particular broker. > In a simple 2 broker cluster, this avoids the need for a durable subscriber > to know about its broker, the balancer will only allow it to connect to the > right one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3523. > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Fix For: 2.20.0 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3544) HawtIO Plugin OSGi import packages
[
https://issues.apache.org/jira/browse/ARTEMIS-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3544.
> HawtIO Plugin OSGi import packages
> --
>
> Key: ARTEMIS-3544
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3544
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: osgi, Web Console
>Affects Versions: 2.19.0
>Reporter: Benjamin Graf
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The build of artemis-plugin (HawtIO plugin) actually generates package import
> of javax.servlet with a narrow version range
> {noformat}javax.servlet;version="[2.6,3)"{noformat}
> even it is build against a 3.0 servlet API dependency. It might be better to
> export it like this
> {noformat}javax.servlet;version="2.6"{noformat} via osgi.import property
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3581) Allow setMaxSizeBytes(0) to indicate an address that will always page
[
https://issues.apache.org/jira/browse/ARTEMIS-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3581.
> Allow setMaxSizeBytes(0) to indicate an address that will always page
> -
>
> Key: ARTEMIS-3581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3581
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently for force paging on an address, for a DLQ for example, you would
> set {{max-size-bytes}} to some small number, e.g.:
> {code:xml}
>PAGE
>1{code}
> However, the broker will complain with:
> {noformat}
> 2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation: java.lang.IllegalStateException:
> java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize.
> Normally pageSize should be significantly smaller than maxSize, ms: 1 ps
> 1024{noformat}
> You could go ahead and downsize the {{page-size-bytes}} as well, but you
> don't want to cripple de-page or page-in and use a reasonable value and some
> memory!
> {code:xml}
>PAGE
>256
>128{code}
> It _should_ be sufficient to just set:
> {code:xml}
>PAGE
>0{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-649) Improve or deprecate the HTML based JMX reports.
[ https://issues.apache.org/jira/browse/ARTEMIS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-649. --- > Improve or deprecate the HTML based JMX reports. > > > Key: ARTEMIS-649 > URL: https://issues.apache.org/jira/browse/ARTEMIS-649 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John D. Ament >Assignee: Justin Bertram >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ActiveMQServerControlImpl, JMSServerManagerImpl uses Java to generate HTML, > for a status report > This can be done better with templating tools like freemarker or velocity, > and alleviate the manual string manipulation. We can also leverage the type > safe POJOs. > Or, it looks like these methods are generally not recommended for use (see > discussion below). Based on this, we may want to consider deprecating > instead of replacing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3115) Incorrect default call-failover-timeout on clusterConnection in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3115. > Incorrect default call-failover-timeout on clusterConnection in broker.xml > -- > > Key: ARTEMIS-3115 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3115 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: Mikhail Lukyanov >Assignee: Justin Bertram >Priority: Major > Fix For: 2.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > ClusterConnectionConfiguration uses > ActiveMQDefaultConfiguration.getDefaultClusterCallFailoverTimeout() > = -1 > broker.xml uses in > FileConfigurationParser > ActiveMQClient.DEFAULT_CALL_FAILOVER_TIMEOUT = 3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3433.
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
> ~[?:?] at
> org.apache.felix.scr.impl.ma
[jira] [Closed] (ARTEMIS-3542) Avoid requesting the root attribute when binding a user to LDAP
[ https://issues.apache.org/jira/browse/ARTEMIS-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3542. > Avoid requesting the root attribute when binding a user to LDAP > --- > > Key: ARTEMIS-3542 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3542 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently the bindUser-method of the LDAPLoginModule tries to verify the user > through requesting the root attribute of the LDAP tree. This check fails if > the user is not allowed to access the root element although everything else > is working properly. > To fix this problem the user should only request its own LDAP attribute as > this will always be possible. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3502) Auto delete of a queue could lead to inconsistencies
[ https://issues.apache.org/jira/browse/ARTEMIS-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3502. > Auto delete of a queue could lead to inconsistencies > > > Key: ARTEMIS-3502 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3502 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.19.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Auto delete might happen after a disconnect of consumers. > on a situation where the consumer was up to date the queue could be removed, > leading to a few issues. > we should improve how we handle with auto-delete and avoid these > inconsistencies. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3515) Adding an example with broker connection and multicast
[ https://issues.apache.org/jira/browse/ARTEMIS-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3515. > Adding an example with broker connection and multicast > -- > > Key: ARTEMIS-3515 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3515 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.19.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3543) Artemis client doesn't support encrypted passwords in composite urls
[
https://issues.apache.org/jira/browse/ARTEMIS-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3543.
> Artemis client doesn't support encrypted passwords in composite urls
>
>
> Key: ARTEMIS-3543
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3543
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Artemis Client doesn't support encrypted passwords in composite urls:
> {code}
> SECURE_PASS=securepass
> ENC_SECURE_PASS=$(./bin/artemis mask securepass)
> ENC_SECURE_PASS="ENC(${ENC_SECURE_PASS:8})"
> ./bin/artemis create broker --user admin --password admin --require-login
> keytool -storetype pkcs12 -keystore ./broker/etc/server-keystore.p12
> -storepass $SECURE_PASS -keypass $SECURE_PASS -alias server -genkey -keyalg
> "RSA" -keysize 2048 -dname "CN=ActiveMQ Artemis Server, OU=Artemis,
> O=ActiveMQ, L=AMQ, S=AMQ, C=AMQ" -validity 36500 -ext bc=ca:false -ext eku=sA
> -ext san=dns:localhost,ip:127.0.0.1
> keytool -storetype pkcs12 -keystore ./broker/etc/server-keystore.p12
> -storepass $SECURE_PASS -keypass $SECURE_PASS -alias server -exportcert -rfc
> > server.crt
> keytool -storetype pkcs12 -keystore ./broker/etc/server-truststore.p12
> -storepass $SECURE_PASS -keypass $SECURE_PASS -importcert -alias server -file
> server.crt -noprompt
> sed -i
> "s/0.0.0.0:61616?/0.0.0.0:61616?sslEnabled=true;keyStorePath=server-keystore.p12;keyStorePassword=$ENC_SECURE_PASS;/g"
> ./broker/etc/broker.xml
> ./broker/bin/artemis run
> ./broker/bin/artemis producer --verbose --destination queue://TEST.QUEUE
> --user admin --password admin --protocol core --message-count 1 --url
> "(tcp://localhost:61616)?sslEnabled=true&trustStorePath=./broker/etc/server-truststore.p12&trustStorePassword=$ENC_SECURE_PASS"
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3420. > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.20.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.20.0). > An existing release stream (e.g. from 2.18.0 as of report, 2.19.0 soon) could > be used for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, -RC2 is due later this > week-, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3559) Update netty version to 4.1.72.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3559. > Update netty version to 4.1.72.Final > > > Key: ARTEMIS-3559 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3559 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Update netty version to 4.1.72.Final and netty-tcnative version to > 2.0.46.Final. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3569) Broker balancer based on authenticated user role assignment
[
https://issues.apache.org/jira/browse/ARTEMIS-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3569.
> Broker balancer based on authenticated user role assignment
> ---
>
> Key: ARTEMIS-3569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3569
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: balancer
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> following up on ARTEMIS-3365 for the local target path.
> add support for ROLE_NAME as a targetKey.
> Matching one of the Roles of an authenticated principal associated with a
> connection, accept or reject the connection based on some partition policy
> based on the role.
> Using the existing regular expression based filter, it is possible to ensure
> a sub set of roles are associated with a given broker.
> The symmeteric-simple-example that uses the client id key type can be
> extended to support partitioning on role assignment, the configuration, to
> use role names that begin with "PARTITION_" and match "PARTITION_FOO" to
> this broker, would be of the form:
> {code:java}
>
> ROLE_NAME
> ^PARTITION_*
> ^PARTITION_FOO.*
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3529) Expire move should not reject duplicates from duplicateID
[ https://issues.apache.org/jira/browse/ARTEMIS-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3529. > Expire move should not reject duplicates from duplicateID > - > > Key: ARTEMIS-3529 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3529 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The issue is that duplicateID makes sense with client to server.. and the > move should ignore it. > You could have two independent queues with the same ID from each one, and the > move should still succeed. > Also, the message could be retried and a second retry should not test > duplicate reject again. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3574) Allow multiple bindings for embedded webserver
[ https://issues.apache.org/jira/browse/ARTEMIS-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3574. > Allow multiple bindings for embedded webserver > -- > > Key: ARTEMIS-3574 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3574 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > At the moment it is only possible to configure one binding for the embedded > jetty webserver to listen on. It would be great to have the possibility to > configure multiple bindings for different war-files in order to serve those > files on different ports and allow the usage of http and https at the same > time. > My current problem is the usage of the prometheus metrics plugin. In our > setup it is not possible to call the "/metrics" endpoint with SSL enabled. > Therefore I would like to define a second binding without SSL enabled for > this plugin. Disabling SSL completely is not an option as other endpoints > like the jolokia-api and the web-console require some user authentication > which should be protected. > The idea is to move all binding related configuration parameters of the > "web" element and the configured "apps" in "bootstrap.xml" to a new element > called "binding" and put a list of those "binding" elements inside the "web" > element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3564) update to Qpid JMS 1.3.0
[ https://issues.apache.org/jira/browse/ARTEMIS-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3564. > update to Qpid JMS 1.3.0 > > > Key: ARTEMIS-3564 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3564 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.20.0 > > > Update to Qpid JMS 1.3.0, now that ARTEMIS-3420 is in. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2293) addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[
https://issues.apache.org/jira/browse/ARTEMIS-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2293.
> addPacket method in the
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl
> doesn't notify threads in case of an Exception
> ---
>
> Key: ARTEMIS-2293
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2293
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.19.0
>Reporter: Pavel Molchanov
>Priority: Major
> Fix For: 2.20.0
>
> Attachments: 13035609_ARTEMIS-2293-Test.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Block that handles exceptions in the catch(Exception e) doesn't call
> notifyAll(). That cause that other working threads are not released in the
> waitCompletion method.
> [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java]
>
> addPacket method:
> {code:java}
> public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues)
> {
> int flowControlCredit = 0;
>
> synchronized (this) {
> packetAdded = true;
> if (outStream != null) {
> try {
> if (!isContinues) {
> streamEnded = true;
> }
>
> if (fileCache != null) {
> fileCache.cachePackage(chunk);
> }
>
> outStream.write(chunk);
>
> flowControlCredit = flowControlSize;
>
> notifyAll();
>
> if (streamEnded) {
> outStream.close();
> }
> } catch (Exception e) {
> ActiveMQClientLogger.LOGGER.errorAddingPacket(e);
> handledException = e;
> }
> } else {
> if (fileCache != null) {
> try {
> fileCache.cachePackage(chunk);
> } catch (Exception e) {
> ActiveMQClientLogger.LOGGER.errorAddingPacket(e);
> handledException = e;
> }
> }
>
> largeMessageData.offer(new LargeData(chunk, flowControlSize,
> isContinues));
> }
> }{code}
>
> waitCompletion method:
> {code:java}
> public synchronized boolean waitCompletion(final long timeWait) throws
> ActiveMQException {
> if (outStream == null) {
> // There is no stream.. it will never achieve the end of streaming
> return false;
> }
>
> long timeOut;
>
> // If timeWait = 0, we will use the readTimeout
> // And we will check if no packets have arrived within readTimeout
> milliseconds
> if (timeWait != 0) {
> timeOut = System.currentTimeMillis() + timeWait;
> } else {
> timeOut = System.currentTimeMillis() + readTimeout;
> }
>
> while (!streamEnded && handledException == null) {
> try {
> this.wait(timeWait == 0 ? readTimeout : timeWait);
> } catch (InterruptedException e) {
> throw new ActiveMQInterruptedException(e);
> }
>
> if (!streamEnded && handledException == null) {
> if (timeWait != 0 && System.currentTimeMillis() > timeOut) {
> throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage();
> } else if (System.currentTimeMillis() > timeOut && !packetAdded) {
> throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage();
> }
> }
> }
>
> checkException();
>
> return streamEnded;
>
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3531) adding documentation for management-message-attribute-size-limit
[ https://issues.apache.org/jira/browse/ARTEMIS-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3531. > adding documentation for management-message-attribute-size-limit > > > Key: ARTEMIS-3531 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3531 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0, 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The documentation pages do not mention configuration parameter > `management-message-attribute-size-limit`. This parameter is used to control > which part (size) of the messages can be browsed. it was introduced in 2.18.0 > to solve out-of-memory problems. > PR will be supplied... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3140) Support com.sun.jndi.ldap.tls.cbtype in LDAPLoginModule
[
https://issues.apache.org/jira/browse/ARTEMIS-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3140.
> Support com.sun.jndi.ldap.tls.cbtype in LDAPLoginModule
> ---
>
> Key: ARTEMIS-3140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3140
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.17.0
>Reporter: Panu Hämäläinen
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Microsoft has added the following binding feature to LDAP connections
> (AD/Domain Controllers):
> [https://support.microsoft.com/en-us/topic/use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e]
>
> To interoperate with this Java has required some changes which are available
> at least in a Java 16 release candidate:
> [https://bugs.openjdk.java.net/browse/JDK-8245527]
> That is, to make Java add the required channel binding information to its
> LDAP connection, the JNDI environment property
> \{{com.sun.jndi.ldap.tls.cbtype}} must be set to \{{tls-server-end-point}}.
> However, Artemis LDAPLoginModule creates an internal environment object which
> does not support the property.
>
> I would also propose to improve the LDAPLoginModule class in a way that any
> future custom/added property could be included to the JNDI environment
> without requiring changes to the actual code.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3496) Replica connection to its live should fail fast
[
https://issues.apache.org/jira/browse/ARTEMIS-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3496.
> Replica connection to its live should fail fast
> ---
>
> Key: ARTEMIS-3496
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3496
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Both SharedNothingBackupActivation and ReplicationBackupActivation set
> session factory's cluster control reconnect attempts to 1, but the comment on
> the code for the former says:
> {code:java}
> //we should only try once, if its not there we should move on.
> {code}
> That doesn't look right, indeed, in case of failed cluster connection due to
> TTL, the additional attempt to reconnect slow down the whole failover process.
> As per the comment, to try connect just once, reconnect attempts should be
> set to 0.
> The weird thing is that the same session factory is created (along with the
> initial connection) with reconnectAttempts == 0 by
> ClusterController::connectToNodeInReplicatedCluster, before authorizing and
> starting the initial sync.
> Need an investigation to find out why it seems to be set to 1 from the
> original correct value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3533) Have federation configuration respect extra url parameters from the connector-ref
[ https://issues.apache.org/jira/browse/ARTEMIS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3533. > Have federation configuration respect extra url parameters from the > connector-ref > - > > Key: ARTEMIS-3533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3533 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.18.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > a connector ref with a url of the form: > "tcp://localhost:61616?ackBatchSize=100&consumerWindowSize=-1" > should be capable of configuring the ServerLocator used by a federation > client. > These are ignored by the transport connector but are captured as > extraParameters in the internal configuration. > It is simply a case of applying them. currently they are ignored! > This is better than duplicating additional serverLocator configuration in > federation configuration. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3528) Only enable JVM debug options for 'run' command
[
https://issues.apache.org/jira/browse/ARTEMIS-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3528.
> Only enable JVM debug options for 'run' command
> ---
>
> Key: ARTEMIS-3528
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3528
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is what happens if I try to add a new user from the same machine where
> the broker instance is running in debug mode ({{etc/artemis.profile}},
> DEBUG_ARGS enabled):
> {noformat}
> $ bin/artemis user add --url tcp://localhost:61616 --user admin --password
> admin \
> --user-command-user foo --user-command-password foo --role amq
> ERROR: transport error 202: bind failed: Address already in use
> ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
> JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
> [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:735]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3308.
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3537) update to proton-j 0.33.10
[ https://issues.apache.org/jira/browse/ARTEMIS-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3537. > update to proton-j 0.33.10 > -- > > Key: ARTEMIS-3537 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3537 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: AMQP >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: 2.20.0 > > > update to proton-j 0.33.10 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3540) SimpleSymmetricClusterTest.testSimpleRestartClusterConnection fix
[ https://issues.apache.org/jira/browse/ARTEMIS-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3540. > SimpleSymmetricClusterTest.testSimpleRestartClusterConnection fix > - > > Key: ARTEMIS-3540 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3540 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Reporter: Tiago Bueno >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > SimpleSymmetricClusterTest.testSimpleRestartClusterConnection implemented by > ARTEMIS-3491 may fail on some scenarios because of the cluster connection > stop method creates a thread to stop the bridge but clear the cluster > connection records just after it leading to a failure in the test. > During the test by checking only the records map size is not enough and need > additional checking to ensure the bridge is stopped. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3552) NullPointerException on message expiration
[
https://issues.apache.org/jira/browse/ARTEMIS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3552.
Resolution: Fixed
> NullPointerException on message expiration
> --
>
> Key: ARTEMIS-3552
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3552
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.19.0
>Reporter: Tobias Månsson
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After updating to 2.19.0, we started seeing this error on a address without
> consumers.
> The address sits after a divert, if that could have any affect. The only
> difference to other addresses and diverts, is that there are no consumer on
> this "in" address.
> Our setup is:
> *Two node ON_DEMAND cluster*
> *multicast "out"address > non-exclusive divert > anycast "in"-address*
> We have incoming and outgoing interceptors on all addresses. for modifying
> properties and annotations.
> {code:java}
> WARN [org.apache.activemq.artemis.core.server] AMQ222145: Error expiring
> reference Reference[5511]:NON-RELIABLE:AMQPStandardMessage( [durable=false,
> messageID=5511, address=in, size=1097, applicationProperties={...},
> messageAnnotations={...}, extraProperties =
> TypedProperties[_AMQ_ORIG_QUEUE=3,_AMQ_AD=in,_AMQ_ORIG_ROUTING_TYPE=1,_AMQ_ORIG_ADDRESS=out,_AMQ_ORIG_MESSAGE_ID=5510]]
> 0n queue: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.move(QueueImpl.java:3395)
> [artemis-server-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.expire(QueueImpl.java:3579)
> [artemis-server-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1000(QueueImpl.java:129)
> [artemis-server-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$ExpiryScanner.run(QueueImpl.java:2508)
> [artemis-server-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.19.0.jar:2.19.0]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.19.0.jar:2.19.0]
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) [java.base:]
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.19.0.jar:2.19.0]{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3556) Artemis console should show the message protocol
[ https://issues.apache.org/jira/browse/ARTEMIS-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3556. Resolution: Fixed > Artemis console should show the message protocol > > > Key: ARTEMIS-3556 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3556 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.20.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.20.0 > > Attachments: image-2021-11-05-23-07-36-340.png, screenshot-3.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > When browsing messages in the Artemis Console, the page does not show the > message protocol. Expert users could derive that information from the > available message keys, but there is no formal indication of the message > protocol. > I have prepared a PR that shows the message protocol in the "Headers" table > when viewing message details. The new field is "protocol". > For each message type, the well-know protocol code is shown. > The following class diagram shows which protocols may be shown (please ignore > the interfaces and abstract classes): > !image-2021-11-05-23-07-36-340.png! > my guess is that only AMQP(Standard/Large)Message, OpenwireMessage and > CoreMessage can occur during normal use. > other protocol types are technically possible, these will show their java > class name. > since the protocol is technically not a property of the message, there are > valid arguments for showing this differently. but this is by far the simplest > visualization. > sample: > !screenshot-3.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3539) Allow a shared single connection in the Resource Adaptor
[ https://issues.apache.org/jira/browse/ARTEMIS-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3539. Fix Version/s: 2.20.0 Resolution: Fixed > Allow a shared single connection in the Resource Adaptor > > > Key: ARTEMIS-3539 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3539 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: 2.20.0 > > Time Spent: 40m > Remaining Estimate: 0h > > currently there is a 1 to 1 session with connection and session for MDB's, > allow the use of a single connection. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3565) Remove mvnw
[ https://issues.apache.org/jira/browse/ARTEMIS-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3565. Fix Version/s: 2.20.0 Resolution: Fixed > Remove mvnw > --- > > Key: ARTEMIS-3565 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3565 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3578) Save SimpleString duplication and long[] allocation while moving Core messages
[ https://issues.apache.org/jira/browse/ARTEMIS-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3578. Fix Version/s: 2.20.0 Resolution: Fixed > Save SimpleString duplication and long[] allocation while moving Core messages > -- > > Key: ARTEMIS-3578 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3578 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.20.0 > > > After performing a message copy as shown in ARTEMIS-3572, each of the copied > message reference the original address using a fresh SimpleString copy. > The vararg long[] parameter is unused and has been removed to save unecessary > long[] allocation while using a single Long parameter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3586) ActiveMQActivationSpec equals method has switched singleConnection and useJNDI null pointer verification
[ https://issues.apache.org/jira/browse/ARTEMIS-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3586. Resolution: Fixed > ActiveMQActivationSpec equals method has switched singleConnection and > useJNDI null pointer verification > > > Key: ARTEMIS-3586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3586 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.19.0 >Reporter: Tiago Bueno >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The equals method on ActiveMQActivationSpec has a switched null pointer > verification for singleConnection and useJNDI fields. > Since both fields are initialized with a value by default it should not be a > problem but if one of these fields are set as null at some point and then > equals is called it throws a NPE. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3021) OOM due to wrong CORE clustered message memory estimation
[ https://issues.apache.org/jira/browse/ARTEMIS-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3021. Fix Version/s: 2.20.0 Resolution: Fixed > OOM due to wrong CORE clustered message memory estimation > - > > Key: ARTEMIS-3021 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3021 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.20.0 > > Time Spent: 6h > Remaining Estimate: 0h > > This is affecting clustered Core messages (persistent or not). > The process that cause the wrong estimation is: > # add route information to the message > # get memory estimation for paging (ie address size estimation) without > accounting the new route information > # get message persist size for durable append on journal/to update queue > statistics, triggering a re-encoding > # re-encoding (can) enlarge the message buffer to be the next power of 2 > available capacity > The 2 fixes are: > * getting a correct memory estimation of the message (including the added > route information) > * save an excessive buffer growth caused by the default Netty's > ByteBuf::ensureWritable strategy -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3605) Upgrade jetty version to 9.4.44.v20210927
[ https://issues.apache.org/jira/browse/ARTEMIS-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3605. Fix Version/s: 2.20.0 Resolution: Fixed > Upgrade jetty version to 9.4.44.v20210927 > - > > Key: ARTEMIS-3605 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3605 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3567) IllegalStateException on web console logout
[
https://issues.apache.org/jira/browse/ARTEMIS-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3567.
Fix Version/s: 2.20.0
Resolution: Fixed
> IllegalStateException on web console logout
> ---
>
> Key: ARTEMIS-3567
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3567
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis logs an IllegalStateException on web console logout if the
> base audit logger is enabled:
> {code:java}
> 2021-10-29 23:15:37,559 WARN [org.eclipse.jetty.server.HttpChannel]
> /console/auth/login: java.lang.IllegalStateException: Response is committed
> at org.eclipse.jetty.server.Request.getSession(Request.java:1623)
> at org.eclipse.jetty.server.Request.getSession(Request.java:1602)
> at
> org.apache.activemq.artemis.component.AuthenticationFilter.doFilter(AuthenticationFilter.java:48)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2097) Pause and Block Producers
[ https://issues.apache.org/jira/browse/ARTEMIS-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-2097. Fix Version/s: 2.20.0 Resolution: Fixed > Pause and Block Producers > - > > Key: ARTEMIS-2097 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2097 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.5.5 > Environment: AMQ-1.5.5 >Reporter: Tyronne Wickramarathne >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > > Could it be possible to block all incoming messages without changing the > address-full-policy to 'BLOCK'? > The address full policy can be configured to block incoming messages should > the address full policy reaches the configured max-size-bytes attributes. > However, on certain circumstances it is important to make a JMS destination > drain without accepting incoming messages while keeping the > address-full-policy at 'PAGE'. For an instance, if a user needs to bring down > the broker for maintenance, it is important to allow the user to drain > existing messages in the corresponding destination without accepting any new > messages. > > Currently the pause() method on a destination pauses message consumers. In a > similar fashion could it be possible to add a new method to block message > producers on a given destination irrespective of the address-full-policy > being used? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3577) Save Core msg re-encoding due to msg copy
[ https://issues.apache.org/jira/browse/ARTEMIS-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3577. Fix Version/s: 2.20.0 Resolution: Fixed > Save Core msg re-encoding due to msg copy > - > > Key: ARTEMIS-3577 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3577 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.20.0 > > > ARTEMIS-3021 has introduced a check re encoding validity while computing > memory estimate. > It means that if a message modified after being copied and encoded, it would > be re-encoded while computing memory estimation: this is happening while > moving messages, because the destination address is added after checking for > large message that's causing a stealth message encoding. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3566) Stomp Embedded Interceptor Example throws NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3566.
Fix Version/s: 2.20.0
Resolution: Fixed
> Stomp Embedded Interceptor Example throws NPE
> -
>
> Key: ARTEMIS-3566
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3566
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Minor
> Fix For: 2.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> cd examples/protocols/stomp/stomp-embedded-interceptor
> mvn verify
> {code:java}
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.jms.example.StompEmbeddedWithInterceptorExample.main
> (StompEmbeddedWithInterceptorExample.java:79)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.activemq.artemis.maven.ArtemisClientPlugin.doExecute
> (ArtemisClientPlugin.java:61)
> at org.apache.activemq.artemis.maven.ArtemisAbstractPlugin.execute
> (ArtemisAbstractPlugin.java:74)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3601) Expose acceptors via management
[ https://issues.apache.org/jira/browse/ARTEMIS-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3601. Fix Version/s: 2.20.0 Resolution: Fixed > Expose acceptors via management > --- > > Key: ARTEMIS-3601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3601 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3571) pluralization not always correct
[
https://issues.apache.org/jira/browse/ARTEMIS-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3571.
Resolution: Fixed
> pluralization not always correct
>
>
> Key: ARTEMIS-3571
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3571
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When moving multiple messages, the confirmation message says e.g.:
> {noformat}
> Moved 3 message to ExpiryQueues
> {noformat}
> The pluralization is done on the whole sentence instead of just the word
> "message". Note the "s" that is visible at the end of the sentence.
> I've checked all 6 occurrences of {{maybePlural}}, this is the only one that
> needs a fix.
> This is a simple JS fix. A PR is added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3541) destroyQueue ignoring autoDeleteAddress flag
[ https://issues.apache.org/jira/browse/ARTEMIS-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3541. Fix Version/s: 2.20.0 Resolution: Fixed > destroyQueue ignoring autoDeleteAddress flag > > > Key: ARTEMIS-3541 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3541 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.20.0 > > Time Spent: 6h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3570) additional decoding of some known message header fields
[
https://issues.apache.org/jira/browse/ARTEMIS-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3570.
Resolution: Fixed
> additional decoding of some known message header fields
> ---
>
> Key: ARTEMIS-3570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3570
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the "Browse Queue" screen for a single message, the headers and properties
> are shown. Some of these entries have internal values that become much
> clearer when they are decoded.
> * {{_AMQ_Binding_Type}} (visible on notification queues) with its values
> "{{local-queue}}", "{{remote-queue}}" and "{{divert}}"; and
> * {{_AMQ_ROUTING_TYPE}} with its values "{{multicast}}" and "{{anycast}}"; and
> * {{_AMQ_ORIG_Routing_Type}} same for expired message; and
> * {{_AMQ_NotifTimestamp}} as timestamp; and
> * {{extraProperties._AMQ_ACTUAL_EXPIRY}} as timestamp; and
> * {{messageAnnotations.x-opt-ACTUAL-EXPIRY}} as timestamp; and
> * {{properties.creationTime}} as timestamp.
> Some of these properties are only visible on expired messages (so usually on
> the {{ExpiryQueue}}).
> There might be more such fields, but these are encountered in my situation.
> Also added verification so that for any field decoding, when the field is not
> numeric, the decoding is not performed. previously only a check for {{NaN}}
> existed.
> Note that {{extraProperties._AMQ_ACTUAL_EXPIRY}} currently is a string and is
> therefore not actually decoded.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3596) ServiceLoader.load causing issues in OSGi enviroments.
[ https://issues.apache.org/jira/browse/ARTEMIS-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3596. Fix Version/s: 2.20.0 Resolution: Fixed > ServiceLoader.load causing issues in OSGi enviroments. > -- > > Key: ARTEMIS-3596 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3596 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.19.0 >Reporter: Ryan Yeats >Priority: Major > Fix For: 2.20.0 > > Time Spent: 3h > Remaining Estimate: 0h > > Our system runs Artemis inside of Karaf as an OSGi bundle. Starting with > version 2.19.0 of Artemis, Artemis fails to start correctly due to an > exception during the bundle resolution process. The problems happens when the > artemis-server-osgi bundle is reloaded by the bundle resolution process. The > bundle starts correctly the first time, but during the resolution process, an > import Artemis uses is refreshed causing the bundle to be reloaded. > Consequently, the ServiceLoader.load method is called again by the static > initializer block in the SSLContextFactoryProvider class. The > ServiceLoader.load is passed in a class loader is obtained by calling > Thread.currentThread.getContextClassloader(). The first time the static > initializer block is executed, the classes DefaultSSLContextFactory and its > interface, SSLContextFactory, are loaded. However, on reload > Thread.currentThread.getContextClassloader() returns the original > DefaultSSLContextFactory which is no long the one corresponding to the class > loader of the bundle the second time it is started. Resulting in the > following error message: > org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactory: > org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultSSLContextFactory > not a subtype > I believe the best way to fix this is to change > ServiceLoader.load(SSLContextFactory.class, > Thread.currentThread().getContextClassLoader()) > to > ServiceLoader.load(SSLContextFactory.class, > SSLContextFactoryProvider.class.getClassLoader()) > Which for any environment that doesn’t juggle class-loaders like OSGi would > evaluate to the same class-loader. > I also noticed several places that ServiceLoader.load(.class) was > called which should also be changed to pass in the class-loader of the class > since they would default to the thread context class-loader also. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3595) PrintData options to help with visualization
[ https://issues.apache.org/jira/browse/ARTEMIS-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3595. Resolution: Fixed > PrintData options to help with visualization > > > Key: ARTEMIS-3595 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3595 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.19.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Adding a few options to improve looking for data: > --max-pages: To stop printing after a certain number of pages > --skip-bindings: Don't print the bindings journal > --skip-journal: Don't print the messages journal > --highlight-unacked: Helping finding non acked records on paging -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3554) Prepared Transaction with Invalid Data may prevent a server start
[ https://issues.apache.org/jira/browse/ARTEMIS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3554. Fix Version/s: 2.20.0 Resolution: Fixed > Prepared Transaction with Invalid Data may prevent a server start > - > > Key: ARTEMIS-3554 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3554 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Prepare a transaction with an ACK on page > Stop the server > remove the paging files > The server will not start > The transaction should be logged with a warn, rolled back and the server > start normally. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3547) client load balance code can be improved
[ https://issues.apache.org/jira/browse/ARTEMIS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3547. Resolution: Fixed > client load balance code can be improved > > > Key: ARTEMIS-3547 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3547 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.19.0 >Reporter: Jianjiang Mu >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.activemq.artemis.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy > class in aretemis-core-client can be improved! > Two field is used here, one is first(boolean type）and one is pos(int > type).The "first“ field is not necessary here. Only "pos" can do the job. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3600) Add console index page test
[ https://issues.apache.org/jira/browse/ARTEMIS-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3600. Fix Version/s: 2.20.0 Resolution: Fixed > Add console index page test > --- > > Key: ARTEMIS-3600 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3600 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2922) artemis-cli consumer on large message results in a ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2922.
Fix Version/s: 2.20.0
Resolution: Fixed
> artemis-cli consumer on large message results in a ClassCastException
> -
>
> Key: ARTEMIS-2922
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2922
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.15.0, 2.16.0
> Environment: OS: Ubuntu 20.04 lts
> jre/jdk: openjdk version "11.0.8" 2020-07-14
> The broker has been created with
> {quote}bin/artemis create --user admin --password admin --allow-anonymous
> broker
> {quote}
> (no changes in the config)
> The message is produced with
> {quote}artemis producer --data large-test.xml.sav --destination queue://test
> {quote}
>
>Reporter: Oliver Scholz
>Assignee: Justin Bertram
>Priority: Major
> Labels: ClassCastException, LargeMessage, artemis, cli, consumer
> Fix For: 2.20.0
>
> Attachments: large-test.xml.sav
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When i try to consume a Large Message (stored in ../data/large-messages)
> with the artemis-cli
> {quote}{color:#00}artemis consumer --message-count 1 --data
> export-test.xml --destination queue://test{color}
> {quote}
> i get an ClassCastException output
> {quote}{color:#00}Connection brokerURL = tcp://localhost:61616{color}
> {color:#00}Consumer:: filter = null{color}
> {color:#00}Consumer ActiveMQQueue[test], thread=0 wait until 1 messages
> are consumed{color}
> {color:#00}java.lang.RuntimeException: java.lang.ClassCastException:
> class org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl
> cannot be cast to class
> org.apache.activemq.artemis.core.server.LargeServerMessage
> (org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl and
> org.apache.activemq.artemis.core.server.LargeServerMessage are in unnamed
> module of loader java.net.URLClassLoader @18769467){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.factory.serialize.XMLMessageSerializer.write(XMLMessageSerializer.java:74){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.messages.Consumer$SerialiserMessageListener.onMessage(Consumer.java:140){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.messages.ConsumerThread.handle(ConsumerThread.java:73){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.messages.ConsumerThread.consume(ConsumerThread.java:192){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.messages.ConsumerThread.run(ConsumerThread.java:67){color}
> {color:#00}Caused by: java.lang.ClassCastException: class
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl cannot be
> cast to class org.apache.activemq.artemis.core.server.LargeServerMessage
> (org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl and
> org.apache.activemq.artemis.core.server.LargeServerMessage are in unnamed
> module of loader java.net.URLClassLoader @18769467){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.tools.xml.XMLMessageExporter.printMessageBody(XMLMessageExporter.java:61){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.commands.tools.xml.XMLMessageExporter.printSingleMessageAsXML(XMLMessageExporter.java:53){color}
> {color:#00} at
> org.apache.activemq.artemis.cli.factory.serialize.XMLMessageSerializer.write(XMLMessageSerializer.java:72){color}
> {color:#00} ... 4 more{color}
> {color:#00}Consumer ActiveMQQueue[test], thread=0 Consumed: 0
> messages{color}
> {color:#00}Consumer ActiveMQQueue[test], thread=0 Consumer thread
> finished{color}
> {quote}
> Yet, the message was consumed from the queue!
> Also a workaround/fix for exporting Large Messages would be great.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3576) Fix toString methods throwing exceptions
[ https://issues.apache.org/jira/browse/ARTEMIS-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3576. Fix Version/s: 2.20.0 Resolution: Fixed > Fix toString methods throwing exceptions > > > Key: ARTEMIS-3576 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3576 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > A toString method should never throw any exceptions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3568) fixes/improvements on the "Send message" screens
[ https://issues.apache.org/jira/browse/ARTEMIS-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3568. Resolution: Fixed > fixes/improvements on the "Send message" screens > > > Key: ARTEMIS-3568 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3568 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.20.0 > > Attachments: screenshot-3.png > > Time Spent: 20m > Remaining Estimate: 0h > > The "Send message" screen has room for a few (sometimes minor) improvements. > I've bundled them in one PR. > * (fix) fixed delete-header-item on page send-message-to-queue due to broken > js code behind the delete-button (caught by viewing the diff between > addressSendMessage.js and sendMessage.js); > * (fix) fixed format-message on page send-message-to-queue due to broken js > code behind the format-button (this initially led me to believe that the > button would apply syntax-color only, until I saw the intended behaviour on > page send-message-to-address). > all of the below change apply to both send-message-to-queue and > send-message-to-address pages: > * (smallfix) fixed small spelling error in a help-text where "in" was spelled > as "ion"; > * (smallfix) fixed small spelling error in a help-text where "it's" was > spelled as "its"; > * (cosmetic) the dropdown-box for the format selection has been shrunk and > the button placed on the same line; > * (cosmetic) renamed button from "Send message" to "Send Message", just > because the "Add Header" button on the same page also uses capitals. > I read that "CodeEditor" also supported YAML and TOML. But when I tried it > out, the syntax colours only worked for YAML and the reformatting did not > work for any of these two. so that part was dropped before it was even > committed. > note: internally there are 2 "Send message" screens. one to send a message to > an address, the other one to send a message to a queue. these screen look > very similar and have the same title and button name. the 2 screens can be > only be distinguished visually by looking at the help text from the (?) > button just after the page title. of course the one page is used when an > address is selected in the tree; the other when a queue is selected in the > tree. > !screenshot-3.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3489) JdbcLeaseLockTest fails sporadically in CI
[ https://issues.apache.org/jira/browse/ARTEMIS-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3489. Fix Version/s: 2.20.0 Resolution: Fixed > JdbcLeaseLockTest fails sporadically in CI > -- > > Key: ARTEMIS-3489 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3489 > Project: ActiveMQ Artemis > Issue Type: Test >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > JdbcLeaseLockTest fails sporadically in CI: > E.g: > [https://app.travis-ci.com/github/apache/activemq-artemis/jobs/538004665#L3201] > [https://github.com/apache/activemq-artemis/runs/3531185223?check_suite_focus=true#step:5:2094] > https://github.com/apache/activemq-artemis/runs/3507926162?check_suite_focus=true#step:5:2256 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3587) After upgrade: AMQ224107: The Critical Analyzer detected slow paths on the broker.
[ https://issues.apache.org/jira/browse/ARTEMIS-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3587. Fix Version/s: 2.20.0 Resolution: Fixed > After upgrade: AMQ224107: The Critical Analyzer detected slow paths on the > broker. > -- > > Key: ARTEMIS-3587 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3587 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Sebastian T >Priority: Major > Labels: performance > Fix For: 2.20.0 > > Attachments: log_with_stacktrace.log > > Time Spent: 10m > Remaining Estimate: 0h > > After upgrading from Artemis 2.16.0 to 2.19.0 we now receive the following > message a few times a day: > 2021-11-05 05:32:53.641 WARN 3850 --- [eduled-threads)] > o.a.a.a.u.c.CriticalMeasure : Component > org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 4 > 2021-11-05 05:32:53.642 INFO 3850 --- [eduled-threads)] o.a.a.a.c.server >: AMQ224107: The Critical Analyzer detected slow paths on > the broker. It is recommended that you enable trace logs on > org.apache.activemq.artemis.utils.critical while you troubleshoot this issue. > You should disable the trace logs when you have finished troubleshooting. > This message is also logged via ActiveMQServerCriticalPlugin#criticalFailure > however the javadoc says: "This will be called before the broker is stopped." > The broker however is not stopped. So I think the javadoc and the behaviour > of the callback are not in line anymore too. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3593) OOM error on rogue message to Artemis Broker
[
https://issues.apache.org/jira/browse/ARTEMIS-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3593.
Resolution: Fixed
> OOM error on rogue message to Artemis Broker
>
>
> Key: ARTEMIS-3593
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3593
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.2
>Reporter: Viktor Kolomeyko
>Priority: Critical
> Fix For: 2.20.0
>
> Attachments: CrashDump.log, dospayload.binary
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> A problem been reported by a Security Researcher when a Java process running
> an embedded Artemis Broker been sent a handcrafted message:
> {code:sh}
> cat /path/to/dospayload.binary > /dev/tcp//{code}
> resulting OutOfMemory crash, please see attachment.
> The problem is caused by the fact that a 32-bit integer is read from the
> stream and byte array is allocated using this value without performing any
> checks.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3604) Async sends could overflow server with messages in openwire
[ https://issues.apache.org/jira/browse/ARTEMIS-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3604. Resolution: Fixed > Async sends could overflow server with messages in openwire > --- > > Key: ARTEMIS-3604 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3604 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 9h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3607) JsonUtil addToObject should be able to add a JsonValue
[ https://issues.apache.org/jira/browse/ARTEMIS-3607?focusedWorklogId=696627&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-696627 ] ASF GitHub Bot logged work on ARTEMIS-3607: --- Author: ASF GitHub Bot Created on: 15/Dec/21 13:45 Start Date: 15/Dec/21 13:45 Worklog Time Spent: 10m Work Description: clebertsuconic merged pull request #3883: URL: https://github.com/apache/activemq-artemis/pull/3883 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 696627) Time Spent: 20m (was: 10m) > JsonUtil addToObject should be able to add a JsonValue > -- > > Key: ARTEMIS-3607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3607 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Adding a JsonObject to a JsonObject using JsonUtil.addToObject will have a > NPE if the value is JsonValue.NULL (NullableJsonString). When adding a > JsonObject (aka a Map of JsonValues) we should use the to String method but > 'just' add the JsonValue -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3607) JsonUtil addToObject should be able to add a JsonValue
[ https://issues.apache.org/jira/browse/ARTEMIS-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459946#comment-17459946 ] ASF subversion and git services commented on ARTEMIS-3607: -- Commit dd645d0d4ef7526804043bdbb3850546eba16d76 in activemq-artemis's branch refs/heads/main from Emmanuel Hugonnet [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=dd645d0 ] [ARTEMIS-3607]: Supporting JsonValues in JsonUtil.addToArray and JsonUtil.addToObject * When the added Object is of type JsonValue, don't call the toString method on it. Issue: https://issues.apache.org/jira/browse/ARTEMIS-3607 > JsonUtil addToObject should be able to add a JsonValue > -- > > Key: ARTEMIS-3607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3607 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Adding a JsonObject to a JsonObject using JsonUtil.addToObject will have a > NPE if the value is JsonValue.NULL (NullableJsonString). When adding a > JsonObject (aka a Map of JsonValues) we should use the to String method but > 'just' add the JsonValue -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
[ https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459922#comment-17459922 ] Robbie Gemmell commented on ARTEMIS-3610: - The point of having the send with CompletionListener is to get reliable async send, so having the default configuring being to lie about that seems wrong, at least for the persistent messages; the spec provides a door for a still-unreliable behaviour to be driven through in cases where the spec "permits a lower level of reliability" already, i.e cases it already has doors in the sync send behaviour. It also notes though that firing onComplete means the "message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed", which wouldnt be the case here if the normal sync send is actually blocking for persistent messages. > Artemis's Core JMS 2 CompletionListener with persistent messages should work > by default > > > Key: ARTEMIS-3610 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > JMS 2 spec allow non-persistent messages sent to get CompletionListener's > callback called without any response coming from the broker, but persistent > ones should use CompletionListener relying on broker's responses. > Right now if users won't configure confirmationWindowSize (that's -1 by > default), they won't get *any* meaningful behaviour of CompletionListener > both for persistent and non-persistent messages: we should provide a default > configuration of confirmationWindowSize or just allow CompletionListener to > work without configuring any, in order to let persistent messages to work as > by JMS 2 spec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
[ https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459797#comment-17459797 ] Gary Tully edited comment on ARTEMIS-3610 at 12/15/21, 12:04 PM: - The current behaviour where it fires immediately is just wrong from a jms durable send point of view, it is essentially a lie. However it is a very fast way to get bytes to the broker. The network can be saturated and the journal buffer can batch writes and syncs. In a controlled stable environments it can be very performant. This can be beneficial. Maybe it is just a case of documenting that the completion listener callback without a confirmationWindowSize set is a suggestion/lie, and if the user is interested in the true state of the message on the broker, they need to configure a confirmation window and await confirmations from the broker. The produerWindowSize will still limit, and can block, message production if the server does not grant credit. was (Author: gtully): I think the use of completion listener with a persistent message with default (unset) confirmationWindowSize should behave as if confirmationWindowSize=1, essentially blocking behaviour. The current behaviour where it fires immediately is just wrong from a jms durable send point of view, it is essentially a lie. > Artemis's Core JMS 2 CompletionListener with persistent messages should work > by default > > > Key: ARTEMIS-3610 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > JMS 2 spec allow non-persistent messages sent to get CompletionListener's > callback called without any response coming from the broker, but persistent > ones should use CompletionListener relying on broker's responses. > Right now if users won't configure confirmationWindowSize (that's -1 by > default), they won't get *any* meaningful behaviour of CompletionListener > both for persistent and non-persistent messages: we should provide a default > configuration of confirmationWindowSize or just allow CompletionListener to > work without configuring any, in order to let persistent messages to work as > by JMS 2 spec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
[ https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-3610: - Description: JMS 2 spec allow non-persistent messages sent to get CompletionListener's callback called without any response coming from the broker, but persistent ones should use CompletionListener relying on broker's responses. Right now if users won't configure confirmationWindowSize (that's -1 by default), they won't get *any* meaningful behaviour of CompletionListener both for persistent and non-persistent messages: we should provide a default configuration of confirmationWindowSize or just allow CompletionListener to work without configuring any, in order to let persistent messages to work as by JMS 2 spec. was: JMS 2 spec allow non-persistent messages sent to get CompletionListener's callback called without any response coming from the broker, but persistent ones should block OR reliably use the CompletionListener relying on broker's responses. Right now if users won't configure confirmationWindowSize (that's -1 by default), they won't get *any* meaningful behaviour of CompletionListener both for persistent and non-persistent messages: we should provide a default configuration of confirmationWindowSize or just allow CompletionListener to work without configuring any, in order to let persistent messages to work as by JMS 2 spec. > Artemis's Core JMS 2 CompletionListener with persistent messages should work > by default > > > Key: ARTEMIS-3610 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > JMS 2 spec allow non-persistent messages sent to get CompletionListener's > callback called without any response coming from the broker, but persistent > ones should use CompletionListener relying on broker's responses. > Right now if users won't configure confirmationWindowSize (that's -1 by > default), they won't get *any* meaningful behaviour of CompletionListener > both for persistent and non-persistent messages: we should provide a default > configuration of confirmationWindowSize or just allow CompletionListener to > work without configuring any, in order to let persistent messages to work as > by JMS 2 spec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
[ https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459797#comment-17459797 ] Gary Tully commented on ARTEMIS-3610: - I think the use of completion listener with a persistent message with default (unset) confirmationWindowSize should behave as if confirmationWindowSize=1, essentially blocking behaviour. The current behaviour where it fires immediately is just wrong from a jms durable send point of view, it is essentially a lie. > Artemis's Core JMS 2 CompletionListener with persistent messages should work > by default > > > Key: ARTEMIS-3610 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > JMS 2 spec allow non-persistent messages sent to get CompletionListener's > callback called without any response coming from the broker, but persistent > ones should block OR reliably use the CompletionListener relying on broker's > responses. > Right now if users won't configure confirmationWindowSize (that's -1 by > default), they won't get *any* meaningful behaviour of CompletionListener > both for persistent and non-persistent messages: we should provide a default > configuration of confirmationWindowSize or just allow CompletionListener to > work without configuring any, in order to let persistent messages to work as > by JMS 2 spec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
[ https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-3610: - Description: JMS 2 spec allow non-persistent messages sent to get CompletionListener's callback called without any response coming from the broker, but persistent ones should block OR reliably use the CompletionListener relying on broker's responses. Right now if users won't configure confirmationWindowSize (that's -1 by default), they won't get *any* meaningful behaviour of CompletionListener both for persistent and non-persistent messages: we should provide a default configuration of confirmationWindowSize or just allow CompletionListener to work without configuring any, in order to let persistent messages to work as by JMS 2 spec. was: JMS 2 spec allow non-persistent messages sent to get CompletionListener's callback called without any response coming from the broker, but persistent ones should block OR reliably use the CompletionListener relying on broker's responses. Right now if users won't configure confirmationWindowSize (that's -1 by default), they won't get *any* meaningful behaviour of CompletionListener both for persistent and non-persistent messages: we should provide a default configuration of confirmationWindowSize or just allow CompletionListener to work without configuring any, in order to let persistent messages to work as JMS 2 spec suggest re CompletionListener. > Artemis's Core JMS 2 CompletionListener with persistent messages should work > by default > > > Key: ARTEMIS-3610 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > JMS 2 spec allow non-persistent messages sent to get CompletionListener's > callback called without any response coming from the broker, but persistent > ones should block OR reliably use the CompletionListener relying on broker's > responses. > Right now if users won't configure confirmationWindowSize (that's -1 by > default), they won't get *any* meaningful behaviour of CompletionListener > both for persistent and non-persistent messages: we should provide a default > configuration of confirmationWindowSize or just allow CompletionListener to > work without configuring any, in order to let persistent messages to work as > by JMS 2 spec. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3610) Artemis's Core JMS 2 CompletionListener with persistent messages should work by default
Francesco Nigro created ARTEMIS-3610: Summary: Artemis's Core JMS 2 CompletionListener with persistent messages should work by default Key: ARTEMIS-3610 URL: https://issues.apache.org/jira/browse/ARTEMIS-3610 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Francesco Nigro Assignee: Francesco Nigro JMS 2 spec allow non-persistent messages sent to get CompletionListener's callback called without any response coming from the broker, but persistent ones should block OR reliably use the CompletionListener relying on broker's responses. Right now if users won't configure confirmationWindowSize (that's -1 by default), they won't get *any* meaningful behaviour of CompletionListener both for persistent and non-persistent messages: we should provide a default configuration of confirmationWindowSize or just allow CompletionListener to work without configuring any, in order to let persistent messages to work as JMS 2 spec suggest re CompletionListener. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3609) Artemis's Core JMS 2 CompletionListener shouldn't be called within Netty thread
Francesco Nigro created ARTEMIS-3609:
Summary: Artemis's Core JMS 2 CompletionListener shouldn't be
called within Netty thread
Key: ARTEMIS-3609
URL: https://issues.apache.org/jira/browse/ARTEMIS-3609
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Francesco Nigro
Assignee: Francesco Nigro
As this stack trace shows
{code:java}
at
org.apache.activemq.artemis.cli.commands.messages.perf.SkeletalProducerLoadGenerator.onCompletion(SkeletalProducerLoadGenerator.java:142)
at
org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer$CompletionListenerWrapper.sendAcknowledged(ActiveMQMessageProducer.java:542)
at
org.apache.activemq.artemis.core.client.impl.SendAcknowledgementHandlerWrapper.sendAcknowledged(SendAcknowledgementHandlerWrapper.java:43)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext$2.callSendAck(ActiveMQSessionContext.java:233)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext$2.handleResponse(ActiveMQSessionContext.java:221)
at
org.apache.activemq.artemis.core.protocol.core.impl.ResponseCache.handleResponse(ResponseCache.java:56)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handleAsyncResponse(ChannelImpl.java:754)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:810)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:426)
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:394)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1247)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
{code}
the CompletionListener callbacks are called from within Netty event loop,
that's not a good idea because users could block there, causing client to break
and stop responding
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3568) fixes/improvements on the "Send message" screens
[ https://issues.apache.org/jira/browse/ARTEMIS-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3568: --- Fix Version/s: 2.20.0 > fixes/improvements on the "Send message" screens > > > Key: ARTEMIS-3568 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3568 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.20.0 > > Attachments: screenshot-3.png > > Time Spent: 20m > Remaining Estimate: 0h > > The "Send message" screen has room for a few (sometimes minor) improvements. > I've bundled them in one PR. > * (fix) fixed delete-header-item on page send-message-to-queue due to broken > js code behind the delete-button (caught by viewing the diff between > addressSendMessage.js and sendMessage.js); > * (fix) fixed format-message on page send-message-to-queue due to broken js > code behind the format-button (this initially led me to believe that the > button would apply syntax-color only, until I saw the intended behaviour on > page send-message-to-address). > all of the below change apply to both send-message-to-queue and > send-message-to-address pages: > * (smallfix) fixed small spelling error in a help-text where "in" was spelled > as "ion"; > * (smallfix) fixed small spelling error in a help-text where "it's" was > spelled as "its"; > * (cosmetic) the dropdown-box for the format selection has been shrunk and > the button placed on the same line; > * (cosmetic) renamed button from "Send message" to "Send Message", just > because the "Add Header" button on the same page also uses capitals. > I read that "CodeEditor" also supported YAML and TOML. But when I tried it > out, the syntax colours only worked for YAML and the reformatting did not > work for any of these two. so that part was dropped before it was even > committed. > note: internally there are 2 "Send message" screens. one to send a message to > an address, the other one to send a message to a queue. these screen look > very similar and have the same title and button name. the 2 screens can be > only be distinguished visually by looking at the help text from the (?) > button just after the page title. of course the one page is used when an > address is selected in the tree; the other when a queue is selected in the > tree. > !screenshot-3.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3608) OFF_WITH_REDISTRIBUTION - no redistribution for non persistent Multicast messages
Anton Roskvist created ARTEMIS-3608: --- Summary: OFF_WITH_REDISTRIBUTION - no redistribution for non persistent Multicast messages Key: ARTEMIS-3608 URL: https://issues.apache.org/jira/browse/ARTEMIS-3608 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Anton Roskvist When running a cluster with OFF_WITH_REDISTRIBUTION load balancing semantics, non persistent messages sent to a broker without a directly connected consumer results in dropped messages even if a remote one is present. This might be expected behavior but I think it's wrong. Setting OFF_WITH_REDISTRIBUTION I would expect messages to reach a corresponding consumer regardless of where it is connected in the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3607) JsonUtil addToObject should be able to add a JsonValue
[ https://issues.apache.org/jira/browse/ARTEMIS-3607?focusedWorklogId=696431&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-696431 ] ASF GitHub Bot logged work on ARTEMIS-3607: --- Author: ASF GitHub Bot Created on: 15/Dec/21 08:01 Start Date: 15/Dec/21 08:01 Worklog Time Spent: 10m Work Description: ehsavoie opened a new pull request #3883: URL: https://github.com/apache/activemq-artemis/pull/3883 JsonUtil.addToObject * When the added Object is of type JsonValue, don't call the toString method on it. Issue: https://issues.apache.org/jira/browse/ARTEMIS-3607 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 696431) Remaining Estimate: 0h Time Spent: 10m > JsonUtil addToObject should be able to add a JsonValue > -- > > Key: ARTEMIS-3607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3607 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Adding a JsonObject to a JsonObject using JsonUtil.addToObject will have a > NPE if the value is JsonValue.NULL (NullableJsonString). When adding a > JsonObject (aka a Map of JsonValues) we should use the to String method but > 'just' add the JsonValue -- This message was sent by Atlassian Jira (v8.20.1#820001)
