[jira] [Commented] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849057#comment-17849057 ] ASF subversion and git services commented on ARTEMIS-4726: -- Commit c47713454caeece82df29a0a7fd4a2a39000576b in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c47713454c ] ARTEMIS-4726 fix original commit The original commit (1ee3e884b707a659d924188048c2960a3b22df35) for this issue wasn't completely correct. This commit fixes those issues so that both the messageCount and scheduledMessageCount are accurate now when a scheduled message is removed by its ID. > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 50m > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849033#comment-17849033 ] ASF subversion and git services commented on ARTEMIS-4771: -- Commit 3244965155406f6b1904f9ba0e73d0ced4eda298 in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3244965155 ] ARTEMIS-4771 AMQP Large Message Writer no-op staged write if already closed If the writer is closed while flow controlled write attempts are pending in the connection executor an NPE is thrown which should be avoided as the closed state should trigger the writes to stop. Add fix and test that checks that this works as it should. > NPE between AMQPLargeMessageWriter::tryDelivering and resetClose > > > Key: ARTEMIS-4771 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4771 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > > This is using RedHat's bits: > java.lang.NullPointerException: Cannot invoke > "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is > null > at > org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174) > ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9] > at > io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173) > ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at > io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166) > [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at > io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) > [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413) > [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at > io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) > [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at > io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) > [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1] > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848716#comment-17848716 ] ASF subversion and git services commented on ARTEMIS-4726: -- Commit 1ee3e884b707a659d924188048c2960a3b22df35 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1ee3e884b7 ] ARTEMIS-4726 removing scheduled msg from q via mngmnt can cause negative msg count > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 0.5h > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848717#comment-17848717
]
ASF subversion and git services commented on ARTEMIS-4420:
--
Commit e13d65b16d4ac1c5edccc51f99cc7c33994f07f1 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e13d65b16d ]
ARTEMIS-4420 user auth leaks into non-Artemis servlets
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848718#comment-17848718 ] ASF subversion and git services commented on ARTEMIS-4768: -- Commit 7e151ee1cee02496e0552d3be8da034ded4aa08f in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7e151ee1ce ] ARTEMIS-4768 _AMQ_SCHED_DELIVERY msg prop lost after broker restart > Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after > broker restart > > > Key: ARTEMIS-4768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.1, 2.33.0 >Reporter: Ajay P >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Im seeing something peculiar related to messages with Scheduled Delivery on > artemis 2.33.0 and a few prev versions too. > We transmit persistent messages for scheduled delivery with the property > _AMQ_SCHED_DELIVERY set to the time. There is a use case for being able to > browse these queues for scheduled messages and remove them if they need to be > canceled before delivery. This works fine and when browsing the queue using > listScheduledMessages, all properties on said message are visible. We use > this to show a list of scheduled messages that will be transmitted in the > future. > However, if the broker is restarted, then the message does not have that > _AMQ_SCHED_DELIVERY property set anymore. The broker still delivers the > message on the scheduled time but while browsing through the queue messages > that specific property is not on the message. > > Here is a link to a fork with a test case checked in. > [https://github.com/aahrimaan/activemq-scheduled-messages-issue] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848632#comment-17848632
]
ASF subversion and git services commented on AMQ-9504:
--
Commit a12f030090bdf593b4c7bbaf10cd2d553f14bf89 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=a12f03009 ]
AMQ-9504 - Add missing license header
(cherry picked from commit 527d245831fb95fa3a25180ecf404d5a316f2425)
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415)
> at
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93)
> at
> org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251)
> at
>
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848629#comment-17848629
]
ASF subversion and git services commented on AMQ-9504:
--
Commit 527d245831fb95fa3a25180ecf404d5a316f2425 in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=527d24583 ]
AMQ-9504 - Add missing license header
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415)
> at
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93)
> at
> org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251)
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
> at
>
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848630#comment-17848630
]
ASF subversion and git services commented on AMQ-9504:
--
Commit ba3d395fc3f077f41381ad801f2a898caebb1eaa in activemq's branch
refs/heads/activemq-6.1.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ba3d395fc ]
AMQ-9504 - Add missing license header
(cherry picked from commit 527d245831fb95fa3a25180ecf404d5a316f2425)
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:415)
> at
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:93)
> at
> org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:251)
> at
>
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848617#comment-17848617
]
ASF subversion and git services commented on AMQ-9504:
--
Commit c71965176ac4acec78779fbc626c98fc310603e1 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c71965176 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
(cherry picked from commit ddfb36515c0e9588d2e322365f56a3f53fb094ad)
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
>
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848615#comment-17848615
]
ASF subversion and git services commented on AMQ-9504:
--
Commit d719df23007393660547b58c9ff17c3d0bd72f8a in activemq's branch
refs/heads/activemq-6.1.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=d719df230 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
(cherry picked from commit ddfb36515c0e9588d2e322365f56a3f53fb094ad)
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
>
[jira] [Commented] (AMQ-9504) activemq multikahadb persistence adapter with topic wildcard filtered adapter and per destination filtered adapter causes broker failure on restart
[
https://issues.apache.org/jira/browse/AMQ-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848614#comment-17848614
]
ASF subversion and git services commented on AMQ-9504:
--
Commit ddfb36515c0e9588d2e322365f56a3f53fb094ad in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ddfb36515 ]
AMQ-9504 - Prevent registering duplicate mKahadb adapters
This fixes an issue on start up of a broker that is configured with
multiple mKahaDB filtered adapters and one is configured with
perDestination=true. Before this fix a duplicate persistence adapter
could be created because the filter did not check for existing matches.
Patch applied with thanks to Ritesh Adval
> activemq multikahadb persistence adapter with topic wildcard filtered adapter
> and per destination filtered adapter causes broker failure on restart
> ---
>
> Key: AMQ-9504
> URL: https://issues.apache.org/jira/browse/AMQ-9504
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.18.4, 6.1.2
>Reporter: ritesh adval
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 6.2.0, 5.18.5, 6.1.3
>
> Attachments: bugfix.patch, test.patch
>
>
> when using Multikahadb persistence adapter per documentation :
> [https://activemq.apache.org/components/classic/documentation/kahadb] it
> shows that you can use multiple filteredPersistenceAdapters but this does not
> work if you have two filtered adapter where one is using wildcard match for
> topics (or even a specific topic) and second filtered adapter using per
> destination filtered adapter.
> The idea being you want to use one kahadb instance for all the topics and per
> destination kahadb instance for all other destinations like queues. Something
> like this for illustration of the issue see test for more details. (note jmx
> needs to be enabled) :
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> With this setting it works for the first time when broker is started. But as
> soon as you have atleast one topic created which uses wild card filtered
> adapter and you restart the broker, then what happens is there are two
> KahaDBPersistenceAdapter created one by the wildcard (">") topic filtered
> adapter and another one by the second per destination filtered adapter, and
> so second KahaDBPersistenceAdapter fails with below exception:
>
> [INFO] Running org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.20
> s <<< FAILURE! – in
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest
> [ERROR]
> org.apache.activemq.bugs.MultiKahaDBMultipleFilteredAdapterTest.testTopicWildcardAndPerDestinationFilteredAdapter
> – Time elapsed: 11.08 s <<< ERROR!
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:type=Broker,brokerName=localhost,service=PersistenceAdapter,instanceName=KahaDBPersistenceAdapter[/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e|#3a#2f#2f#3e_Index_/mnt/c/Users/ritesh.adval/work/external-repos/activemq/activemq-unit-tests/target/activemq-data/mKahaDB/topic#3a#2f#2f#3e]
> at
> java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at
>
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848261#comment-17848261 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit 98e1389a6e9803554186e0b44cb0be58b9cff276 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=98e1389a6e ] ARTEMIS-4778: clean up configuration test heirarchy, remove hundreds of duplicate tests, isolate parameterized tests > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848264#comment-17848264 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit 3c84f26413bf140244beda32eb46dc5559cecf08 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3c84f26413 ] ARTEMIS-4778: split two Nested test classes (one parameterized, other not) into their own class files > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848265#comment-17848265 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit 7849e2dcbff19da774f3027b619c56516d8ac628 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7849e2dcbf ] ARTEMIS-4778: extract base class and classes from parameterized test with subclass that skips to de-parameterize itself > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848263#comment-17848263 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit 243ea9aa01db65b4c9f1bdf1698dcb5569fa7ba6 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=243ea9aa01 ] ARTEMIS-4778: remove spawn check rule, not needed as the tests dont spawn > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848266#comment-17848266 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit f64d9184066f33a08bf04d6ce75a7649af17b87e in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f64d918406 ] ARTEMIS-4778: rework tests manipulating Xxe config so it is reset after class, and not updated at all for skipped tests > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4778) misc test cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848262#comment-17848262 ] ASF subversion and git services commented on ARTEMIS-4778: -- Commit 3e20687cf3637a941c9199275ed6be51163dc6a8 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3e20687cf3 ] ARTEMIS-4778: replace various assertEquals checks with more apropriate assertTrue / assertFalse / assertNull > misc test cleanup > - > > Key: ARTEMIS-4778 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4778 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.34.0 > > > There are various tests oddites that could be cleaned up, such as: test > classes that have nested classes mixing both parameterized and > non-parameterized, or test classes that have hierarchies that result in > hundreds of duplicate runs of the same self-contained tests from a parent, or > skipping hundreds of tests by 'un-parameterizing' a parent, or tests that > influence static config without restoring it afterwards even in the case of > tests that are being skipped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848227#comment-17848227
]
ASF subversion and git services commented on ARTEMIS-3622:
--
Commit 3c058e98f1e332987aff026e4026758df6ca2785 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3c058e98f1 ]
ARTEMIS-3622 MQTT can deadlock on client cxn/discxn
This commit fixes the deadlock described on ARTEMIS-3622 by moving the
synchronization "up" a level from the MQTTSession to the
MQTTConnectionManager. It also eliminates the synchronization on the
MQTTSessionState in the MQTTConnectionManager because it's no longer
needed. This change should not only eliminate the deadlock, but improve
performance relatively as well.
There is no test associated with this commit as I wasn't able to
reproduce the deadlock with any kind of straight-forward test. There was
a test linked on the Jira, but it involved intrusive and fragile
scaffolding and wasn't ultimately tenable. That said, I did test this
fix with that test and it was successful. In any case, I think static
analysis should be sufficient here as the changes are pretty
straight-forward.
> MQTT can deadlock on client connection / disconnection
> --
>
> Key: ARTEMIS-3622
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3622
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
>Affects Versions: 2.19.0
> Environment: Using the latest java 17 and artemis 2.19 but looking at
> the code, it should affect 2.20 as well.
>Reporter: Marcelo Takeshi Fukushima
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It seems that the {{MQTTProtocolHandler}} and {{MQTTConnectionManager}} are
> on a racing condition and can deadlock themselves on misbehaving clients. I'm
> including the relevant stack trace (ignore thread 11 that is just waiting for
> the lock).
> Looking at the relevant code, it seems that the clean-up thread (88 on the
> {{{}MQTTFailureListener{}}}) starts cleaning up the session state and then
> the session, but when {{MQTTSession.stop}} calls
> {{{}MQTTSessionState.clear{}}}, the session state is no longer the same (a
> racy connection has replaced the session state with a brand new under the
> same client-id).
> I think the methods connect and disconnect on the {{MQTTConnectionManager}}
> could be marked as synchronized as a whole, to prevent racy connects /
> disconnects (but since I don't know all the ins and outs of the code, you
> guys might have a better fix).
> {noformat}
> Found one Java-level deadlock:
> =
> "Thread-11
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> waiting to lock monitor 0x7f6d003368c0 (object 0x00045f29f240, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState),
> which is held by "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)"
> "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> waiting to lock monitor 0x7f6d00336a80 (object 0x00045f2a1068, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession),
> which is held by "Thread-88
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=0.0.0.0-212232499)"
> "Thread-88
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=0.0.0.0-212232499)":
> waiting to lock monitor 0x7f6d003368c0 (object 0x00045f29f240, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState),
> which is held by "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)"
> Java stack information for the threads listed above:
> ===
> "Thread-11
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:150)
> - waiting to lock <0x00045f29f240> (a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState)
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTFailureListener.connectionFailed(MQTTFailureListener.java:37)
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnection.fail(MQTTConnection.java:150)
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread$2.run(RemotingServiceImpl.java:780)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> at
>
[jira] [Commented] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848142#comment-17848142 ] ASF subversion and git services commented on ARTEMIS-4772: -- Commit 3474a393010feb6207c66277dfffa6635ed58166 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3474a39301 ] ARTEMIS-4772: fix build failure from modified PR #4935 commit f7b15e351ef712213e0db1d072a2f0ce84f7bb8e > Expose registered broker plugin class names in JMX > -- > > Key: ARTEMIS-4772 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4772 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.33.0 >Reporter: Marek Napieraj >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Make broker plugin class names available as a JMX Attribute for better > debug/monitoring of Artemis instances. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847968#comment-17847968 ] ASF subversion and git services commented on ARTEMIS-4772: -- Commit f7b15e351ef712213e0db1d072a2f0ce84f7bb8e in activemq-artemis's branch refs/heads/main from m.napieraj [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f7b15e351e ] ARTEMIS-4772 expose broker plugin classes via management > Expose registered broker plugin class names in JMX > -- > > Key: ARTEMIS-4772 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4772 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.33.0 >Reporter: Marek Napieraj >Priority: Minor > Labels: features, pull-request-available > Fix For: 2.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Make broker plugin class names available as a JMX Attribute for better > debug/monitoring of Artemis instances. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4776) Replicated Paged Files may leak as open on replica target
[ https://issues.apache.org/jira/browse/ARTEMIS-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847753#comment-17847753 ] ASF subversion and git services commented on ARTEMIS-4776: -- Commit 49189cd7e63a64fcda947dbd72fd7849348b71c9 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=49189cd7e6 ] ARTEMIS-4776 Pages may leak as open on Replicated Target PagingStore is supposed to send an event to replica on every file that is closed. There are a few situation where the sendClose is being missed and that could generate leaks on the target > Replicated Paged Files may leak as open on replica target > - > > Key: ARTEMIS-4776 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4776 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4763) properties config - support metrics plugin, conversion of .class for non string attributes and empty init
[ https://issues.apache.org/jira/browse/ARTEMIS-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847353#comment-17847353 ] ASF subversion and git services commented on ARTEMIS-4763: -- Commit 2f77ca2abb65f958eac24f309e6f733bf8c6a363 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2f77ca2abb ] ARTEMIS-4763 support .class values for non string attributes, properties config of metrics plugins > properties config - support metrics plugin, conversion of .class for non > string attributes and empty init > -- > > Key: ARTEMIS-4763 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4763 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > the metrics plugin is not a broker plugin, so cannot be initialised via the > broker plugins collection. We can only add .class instances to collections. > The metrics instance is an attribute that needs a class type argument on the > metrics configuration. > supporting a conversion to any non string scalar type using a .class value > will work nicely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4766) gate every newInstance call with a type check on the class to ensure we only call static initialisers of the expected type
[ https://issues.apache.org/jira/browse/ARTEMIS-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847354#comment-17847354 ] ASF subversion and git services commented on ARTEMIS-4766: -- Commit f5973d53e67e6e7fc9eb5c45a30bedc02a76f437 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f5973d53e6 ] ARTEMIS-4766 - validate type before newInstance calls > gate every newInstance call with a type check on the class to ensure we only > call static initialisers of the expected type > -- > > Key: ARTEMIS-4766 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4766 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > On our extension points, where configuration provides the implementation > class name, like plugins or transformers, we need to create an instance of > the configured class at runtime. > We typically know the interface type we are expecting, so we can enforce this > check before we create in instance, in that way we won't every call static > initialises on the wrong type in error. In cases where some gadget can be > injected into our configuration, it will need to be specialised for our > interfaces to be effective, which creates one additional hurdle to jump over. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4773) Performance improvement on page.sync
[ https://issues.apache.org/jira/browse/ARTEMIS-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847311#comment-17847311 ] ASF subversion and git services commented on ARTEMIS-4773: -- Commit 22540cc3ab5802e1b3019f55791a20e5adca8983 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=22540cc3ab ] ARTEMIS-4773 Performance improvement on page.sync the sync should be called outside of the lock. if the file was already closed it should then just be ignored as the data was locked anyway. > Performance improvement on page.sync > > > Key: ARTEMIS-4773 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4773 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > > PagingStoreImpl::ioSync is holding a readWriteLock while calling sync: > https://github.com/apache/activemq-artemis/blob/c523458a9aa4f67ad0e9bdbc5c4733bc88bf55f6/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L516-L529 > However that's causing a contention on adding new data: > at jdk.internal.misc.Unsafe.park(java.base@17.0.11/Native Method) > - parking to wait for <0x8087a170> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at > java.util.concurrent.locks.LockSupport.park(java.base@17.0.11/LockSupport.java:211) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11/AbstractQueuedSynchronizer.java:715) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11/AbstractQueuedSynchronizer.java:938) > at > java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@17.0.11/ReentrantReadWriteLock.java:959) > at > org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.writePage(PagingStoreImpl.java:1249) > at > org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.page(PagingStoreImpl.java:1242) > at > org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.page(PagingStoreImpl.java:1173) > at > org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.addToPage(AbstractJournalStorageManager.java:2256 > To fix that I'm going to remove the sync from the readWriteLock. and Ignore > an alreadyClosedException. > I tested this, and also an user and the improvement was significant, > especially with a slower device (that's actually more common on cloud > providers these days). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847312#comment-17847312 ] ASF subversion and git services commented on ARTEMIS-4774: -- Commit e47d8ea7c15e9dbdf450478b79db948e18f04f31 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e47d8ea7c1 ] ARTEMIS-4774 Fixing PageCounters out of sync after AckMnager retries > PageCounters get out of sync after AckManager > - > > Key: ARTEMIS-4774 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4774 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846083#comment-17846083
]
ASF subversion and git services commented on AMQNET-727:
Commit c458814843d9a137ce9a315365f26cbe0ef5a2e6 in activemq-nms-openwire's
branch refs/heads/main from AndyDeMauriceGEDigital
[ https://gitbox.apache.org/repos/asf?p=activemq-nms-openwire.git;h=c458814 ]
AMQNET-727 Fix sync for pendingAck
* Fix sync for pendingAck
* Add curly braces
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9490) Upgrade to commons-logging 1.3.1
[ https://issues.apache.org/jira/browse/AMQ-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845955#comment-17845955 ] ASF subversion and git services commented on AMQ-9490: -- Commit 4cadbab76cc3d2d97e9be878ddc041fb036c69d6 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=4cadbab76 ] Merge pull request #1214 from jbonofre/AMQ-9490 AMQ-9490: Upgrade to commons-logging 1.3.1 > Upgrade to commons-logging 1.3.1 > > > Key: AMQ-9490 > URL: https://issues.apache.org/jira/browse/AMQ-9490 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9490) Upgrade to commons-logging 1.3.1
[ https://issues.apache.org/jira/browse/AMQ-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845954#comment-17845954 ] ASF subversion and git services commented on AMQ-9490: -- Commit 32b106e4670e26fcc11adabf5b0ac7656523c302 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=32b106e46 ] AMQ-9490: Upgrade to commons-logging 1.3.1 > Upgrade to commons-logging 1.3.1 > > > Key: AMQ-9490 > URL: https://issues.apache.org/jira/browse/AMQ-9490 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845496#comment-17845496 ] ASF subversion and git services commented on ARTEMIS-4743: -- Commit e78136b4294dc61989fe33385f7626535c36c529 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e78136b429 ] ARTEMIS-4743 Renaming --loop-sleep as just --sleep Notice that I'm keeping the old argument here as hidden As I keep using this myself, my brain always go to ./artemis queue stat --sleep So, I think people would feel more comfortable if the parameter was renamed. > Improve CLI Queue Stat Output: Split lines and include internal queue > attribute > --- > > Key: ARTEMIS-4743 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4743 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4770) Update to bouncycastle 1.78
[ https://issues.apache.org/jira/browse/ARTEMIS-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845354#comment-17845354 ] ASF subversion and git services commented on ARTEMIS-4770: -- Commit 77076452f29799b2e6d36e21b1c433f1334c6bd6 in activemq-artemis's branch refs/heads/main from Frederico Alves [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=77076452f2 ] ARTEMIS-4770: Upgrade BouncyCastle to 1.78 This closes #4927 > Update to bouncycastle 1.78 > --- > > Key: ARTEMIS-4770 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4770 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.34.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4769) Update to pem-keystore 2.4.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845353#comment-17845353 ] ASF subversion and git services commented on ARTEMIS-4769: -- Commit daf37ab0e194607e5afcc430b1723251af23339a in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=daf37ab0e1 ] ARTEMIS-4769: update to pem-keystore 2.4.0 > Update to pem-keystore 2.4.0 > > > Key: ARTEMIS-4769 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4769 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.34.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845104#comment-17845104 ] ASF subversion and git services commented on ARTEMIS-4765: -- Commit cd563b49add3c046ae7b2400d9c5342016a21829 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cd563b49ad ] ARTEMIS-4765 DuplicateIDCache on Mirror Target is using 20K elements instead of amqpCredits in this commit I'm storing a binding record with the address-settings for the correct size this is also validating eventual merges of the AddressSettings in the same namespace. > Target Mirror is setting wrong size on duplicate cache > -- > > Key: ARTEMIS-4765 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4765 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Duplicate cache on Mirror target is keeping 20_000 records, even if it's only > supposed to keep 1000 due to AMQP credits. > a Workaround is to set the addressSettings.#.iDCacheSize=1000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4759) Restore compatibility with LiveOnlyPolicyConfiguration
[
https://issues.apache.org/jira/browse/ARTEMIS-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845086#comment-17845086
]
ASF subversion and git services commented on ARTEMIS-4759:
--
Commit 2a43c53bb25c3115a23388db523abaa089e5ba3d in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2a43c53bb2 ]
ARTEMIS-4759 restore compatibility with LiveOnlyPolicyConfiguration
> Restore compatibility with LiveOnlyPolicyConfiguration
> --
>
> Key: ARTEMIS-4759
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4759
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During the work for ARTEMIS-3474
> {{org.apache.activemq.artemis.core.config.ha.LiveOnlyPolicyConfiguration}}
> was deprecated for removal. However, one of the changes broke compatibility
> so that folks who were embedding the broker and using
> {{LiveOnlyPolicyConfiguration}} for their configuration started receiving a
> {{ClassCastException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844488#comment-17844488 ] ASF subversion and git services commented on ARTEMIS-4765: -- Commit abb1a7739eca6f7961a3421cda12d57252168f19 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=abb1a7739e ] Reverting ARTEMIS-4765 I am gettig a few test failures when running the server in soak with Mirroring. I will reapply the changes after some testing. > Target Mirror is setting wrong size on duplicate cache > -- > > Key: ARTEMIS-4765 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4765 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Duplicate cache on Mirror target is keeping 20_000 records, even if it's only > supposed to keep 1000 due to AMQP credits. > a Workaround is to set the addressSettings.#.iDCacheSize=1000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844478#comment-17844478 ] ASF subversion and git services commented on ARTEMIS-4765: -- Commit 946d3338b3394bb91b9e612e123cc4e7352e986e in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=946d3338b3 ] ARTEMIS-4765 Adjusting test parameters > Target Mirror is setting wrong size on duplicate cache > -- > > Key: ARTEMIS-4765 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4765 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Duplicate cache on Mirror target is keeping 20_000 records, even if it's only > supposed to keep 1000 due to AMQP credits. > a Workaround is to set the addressSettings.#.iDCacheSize=1000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844476#comment-17844476 ] ASF subversion and git services commented on ARTEMIS-4765: -- Commit 355c600ea8012c5f95c9428592740824b45d8b86 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=355c600ea8 ] ARTEMIS-4765 DuplicateIDCache on Mirror Target is using 20K elements instead of amqpCredits > Target Mirror is setting wrong size on duplicate cache > -- > > Key: ARTEMIS-4765 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4765 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Duplicate cache on Mirror target is keeping 20_000 records, even if it's only > supposed to keep 1000 due to AMQP credits. > a Workaround is to set the addressSettings.#.iDCacheSize=1000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843884#comment-17843884 ] ASF subversion and git services commented on ARTEMIS-4743: -- Commit 3c46871f7996203903e924e36e71a04619572e98 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3c46871f79 ] ARTEMIS-4743 Allow single line header option This option would restore the previous presentation form without the line split on the header. Also some improvements on loop options > Improve CLI Queue Stat Output: Split lines and include internal queue > attribute > --- > > Key: ARTEMIS-4743 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4743 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4762) Queue Stat throw NPE if executed against old server
[ https://issues.apache.org/jira/browse/ARTEMIS-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843883#comment-17843883 ] ASF subversion and git services commented on ARTEMIS-4762: -- Commit f9e2f0920766633b6bd85cbc4248db14f09198d5 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f9e2f09207 ] ARTEMIS-4762 NPE when running 'artemis queue stat' against older server > Queue Stat throw NPE if executed against old server > --- > > Key: ARTEMIS-4762 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4762 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Start 2.28 server, and run ./artemis queue stat against that server. > You will get a NullPointerException within JSON: > java.lang.NullPointerException: no mapping for internalQueue > at > org.apache.johnzon.core.JsonObjectImpl.valueOrExcpetion(JsonObjectImpl.java:52) > at > org.apache.johnzon.core.JsonObjectImpl.getString(JsonObjectImpl.java:85) > at > org.apache.activemq.artemis.json.impl.JsonObjectImpl.getString(JsonObjectImpl.java:68) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.getColumnSizes(StatQueue.java:293) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.printStats(StatQueue.java:268) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.lambda$printStats$1(StatQueue.java:227) > at > org.apache.activemq.artemis.api.core.management.ManagementHelper.doManagement(ManagementHelper.java:127) > at > org.apache.activemq.artemis.api.core.management.ManagementHelper.doManagement(ManagementHelper.java:111) > at > org.apache.activemq.artemis.cli.commands.messages.BasicConnectionAbstract.performCoreManagement(BasicConnectionAbstract.java:90) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.printStats(StatQueue.java:223) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.singleExeuction(StatQueue.java:212) > at > org.apache.activemq.artemis.cli.commands.queue.StatQueue.execute(StatQueue.java:172) > at > org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4755) Upgrade Jackson to 2.17.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843825#comment-17843825 ] ASF subversion and git services commented on ARTEMIS-4755: -- Commit e8f449973ae8ce7225e439e57a44722d146e4bc1 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e8f449973a ] ARTEMIS-4755 upgrade Jackson to 2.17.0 > Upgrade Jackson to 2.17.0 > - > > Key: ARTEMIS-4755 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4755 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4753) Upgrade CheckStyle to 10.16.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843824#comment-17843824 ] ASF subversion and git services commented on ARTEMIS-4753: -- Commit d568f0dd85ba1eb031817e2e9e76ff1021c84980 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=d568f0dd85 ] ARTEMIS-4753 upgrade Checkstyle to 10.16.0 > Upgrade CheckStyle to 10.16.0 > - > > Key: ARTEMIS-4753 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4753 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4751) Upgrade to Apache parent 32
[ https://issues.apache.org/jira/browse/ARTEMIS-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843826#comment-17843826 ] ASF subversion and git services commented on ARTEMIS-4751: -- Commit eac816f6bd592ea0f06cbf08b410362ff4e48e3e in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=eac816f6bd ] ARTEMIS-4751 upgrade to Apache parent 32 Due to https://github.com/apache/maven-apache-parent/pull/188 the property `maven.compiler.release` is now being set which precludes exporting and using any internal Java classes. Therefore this commit removed references to `--add-exports` from the build, switches to reflection, and adds `--add-opens` to the runtime JVM parameters. > Upgrade to Apache parent 32 > --- > > Key: ARTEMIS-4751 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4751 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4757) Upgrade Netty to 4.1.109.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843822#comment-17843822 ] ASF subversion and git services commented on ARTEMIS-4757: -- Commit 732b6dbcdac774fed0049b5daf7366a967bcfa78 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=732b6dbcda ] ARTEMIS-4757 upgrade Netty to 4.1.109.Final > Upgrade Netty to 4.1.109.Final > -- > > Key: ARTEMIS-4757 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4757 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4756) Upgrade Commons IO to 2.16.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843823#comment-17843823 ] ASF subversion and git services commented on ARTEMIS-4756: -- Commit cb69d2b2f96489f503c8a603ebd2fd5c8a04a59e in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cb69d2b2f9 ] ARTEMIS-4756 upgrade Commons IO to 2.16.1 > Upgrade Commons IO to 2.16.1 > > > Key: ARTEMIS-4756 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4756 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9491) Upgrade to ASM 9.7
[ https://issues.apache.org/jira/browse/AMQ-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843716#comment-17843716 ] ASF subversion and git services commented on AMQ-9491: -- Commit f03443ee98d95ae27031e11dab01fa34575b1cbf in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=f03443ee9 ] AMQ-9491: Upgrade to ASM 9.7 > Upgrade to ASM 9.7 > -- > > Key: AMQ-9491 > URL: https://issues.apache.org/jira/browse/AMQ-9491 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9501) Upgrade activemq-bom to 6.2.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/AMQ-9501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843713#comment-17843713 ] ASF subversion and git services commented on AMQ-9501: -- Commit 5b99ad79edc32f0988fd006a66ddf9d54f0c in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=5b99ad79e ] Merge pull request #1220 from kenliao94/upgrade_maven_shade_plugin [AMQ-9501] Upgrade activemq-bom to 6.2.0-snapshot > Upgrade activemq-bom to 6.2.0-SNAPSHOT > -- > > Key: AMQ-9501 > URL: https://issues.apache.org/jira/browse/AMQ-9501 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Ken Liao >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now activemq-bom is pointing to 6.1.1-SNAPSHOT which caused a build > failure after upgraded. > > The task is to upgrade to 6.2.0-SNAPSHOT -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9499) Upgrade to maven-shade-plugin 3.5.3
[ https://issues.apache.org/jira/browse/AMQ-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843714#comment-17843714 ] ASF subversion and git services commented on AMQ-9499: -- Commit f444fae332734d1ccd44f47f26fdcd2314bef5ea in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=f444fae33 ] AMQ-9499: Upgrade to maven-shade-plugin 3.5.3 > Upgrade to maven-shade-plugin 3.5.3 > --- > > Key: AMQ-9499 > URL: https://issues.apache.org/jira/browse/AMQ-9499 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9499) Upgrade to maven-shade-plugin 3.5.3
[ https://issues.apache.org/jira/browse/AMQ-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843715#comment-17843715 ] ASF subversion and git services commented on AMQ-9499: -- Commit 17aaff3709683a8accf626388f32816d1ec7e8b3 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=17aaff370 ] Merge pull request #1217 from jbonofre/AMQ-9499 AMQ-9499: Upgrade to maven-shade-plugin 3.5.3 > Upgrade to maven-shade-plugin 3.5.3 > --- > > Key: AMQ-9499 > URL: https://issues.apache.org/jira/browse/AMQ-9499 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9491) Upgrade to ASM 9.7
[ https://issues.apache.org/jira/browse/AMQ-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843717#comment-17843717 ] ASF subversion and git services commented on AMQ-9491: -- Commit 85f82035cda1bca7ee7acb22b015d2965e37c676 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=85f82035c ] Merge pull request #1215 from jbonofre/AMQ-9491 AMQ-9491: Upgrade to ASM 9.7 > Upgrade to ASM 9.7 > -- > > Key: AMQ-9491 > URL: https://issues.apache.org/jira/browse/AMQ-9491 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9489) Upgrade to commons-io 2.16.1
[ https://issues.apache.org/jira/browse/AMQ-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843392#comment-17843392 ] ASF subversion and git services commented on AMQ-9489: -- Commit 0f520f1e2744f2d3938202b6d62df1e667cd375f in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=0f520f1e2 ] Merge pull request #1213 from jbonofre/AMQ-9489 AMQ-9489: Upgrade to commons-io 2.16.1 > Upgrade to commons-io 2.16.1 > > > Key: AMQ-9489 > URL: https://issues.apache.org/jira/browse/AMQ-9489 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9489) Upgrade to commons-io 2.16.1
[ https://issues.apache.org/jira/browse/AMQ-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843391#comment-17843391 ] ASF subversion and git services commented on AMQ-9489: -- Commit 626932c1c536843cc55ffcde3f02b5f5fda3de26 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=626932c1c ] AMQ-9489: Upgrade to commons-io 2.16.1 > Upgrade to commons-io 2.16.1 > > > Key: AMQ-9489 > URL: https://issues.apache.org/jira/browse/AMQ-9489 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843093#comment-17843093 ] ASF subversion and git services commented on ARTEMIS-4743: -- Commit 054f7e2e85097e9bc6303dfb1e3ce16b5af65dc2 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=054f7e2e85 ] ARTEMIS-4743 Improve Queue Stat output by allowing --loop as an option > Improve CLI Queue Stat Output: Split lines and include internal queue > attribute > --- > > Key: ARTEMIS-4743 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4743 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 3h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4758) Hardening Mirroring
[ https://issues.apache.org/jira/browse/ARTEMIS-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843088#comment-17843088 ] ASF subversion and git services commented on ARTEMIS-4758: -- Commit c523458a9aa4f67ad0e9bdbc5c4733bc88bf55f6 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c523458a9a ] ARTEMIS-4758 Hardening Mirroring This is a list of improvements done as part of this commit / task: * Page Transactions on mirror target are now optional. If you had an interrupt mirror while the target destination was paging, duplicate detection would be ineffective unless you used paged transactions Users can now configure the ack manager retries intervals. Say you need some time to remove a consumer from a target mirror. The delivering references would prevent acks from happening. You can allow bigger retry intervals and number of retries by tinkiering with ack manager retry parameters. * AckManager restarted independent of incoming acks The ackManager was only restarted when new acks were coming in. If you stopped receiving acks on a target server and restarted that server with pending acks, those acks would never be exercised. The AckManager is now restarted as soon as the server is started. > Hardening Mirroring > --- > > Key: ARTEMIS-4758 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4758 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > I have been extensively testing mirroring, and I'm hardening it as an overal > task, improving its behavior: > - Page Transactions on mirror target are now optional. > * If you had an interrupt mirror while the target destination was paging, > duplicate detection would be ineffective unless you used paged transactions > * Users can now configure the ack manager retries intervals. > Say you need some time to remove a consumer from a target mirror. The > delivering references would prevent acks from happening. You can allow bigger > retry intervals and number of retries by tinkiering with ack manager retry > parameters. > * The ackManager was only restarted when new acks were coming in. If you > stopped receiving acks on a target server and restarted that server with > pending acks, those acks would never be exercised. The AckManager retries are > now restarted as soon as the server is started. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4749) SIMILAR_BRANCHES.SWITCH in ../activemq/artemis/utils/ThreadDumpUtil.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843067#comment-17843067
]
ASF subversion and git services commented on ARTEMIS-4749:
--
Commit afd7951eb20f995347c17b6dc9d8b29ad4f83ba9 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=afd7951eb2 ]
ARTEMIS-4749 simplify switch in ThreadDumpUtil
> SIMILAR_BRANCHES.SWITCH in ../activemq/artemis/utils/ThreadDumpUtil.java
>
>
> Key: ARTEMIS-4749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4749
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.25.0
>Reporter: e.bykhanova
>Assignee: Justin Bertram
>Priority: Minor
> Attachments: image-2024-05-01-13-29-32-686.png,
> image-2024-05-01-13-30-38-262.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The static analyzer has detected SIMILAR_BRANCHES.SWITCH: we have identical
> branches in switch node in [private static String threadInfoToString]
> [https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/ThreadDumpUtil.java#L106-L113|#L106-L113]
>
> !image-2024-05-01-13-30-38-262.png|width=663,height=411!
>
> It seems better to change code this way:
>
> {{case WAITING:}}
> {{case TIMED_WAITING:}}
> {{ sb.append("\t- waiting on " +
> threadInfo.getLockInfo());}}
> {{ sb.append('\n');}}
> {{ break;}}
> {{ default:}}
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1769) Return JMS Session's ClientID via JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843006#comment-17843006 ] ASF subversion and git services commented on ARTEMIS-1769: -- Commit b209dd013d0b2e4c3c33e7826f61bd0a1ab9101c in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b209dd013d ] ARTEMIS-1769 mitigate null > Return JMS Session's ClientID via JMX > - > > Key: ARTEMIS-1769 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1769 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Maxim Kalina >Assignee: Justin Bertram >Priority: Minor > Labels: patch > Fix For: 2.34.0 > > Attachments: return_jms_session's_clientID_via_JMX_if_exists.patch > > Time Spent: 40m > Remaining Estimate: 0h > > As discussed in the mailing list, currently there is no possibility to get > the JMS session's *clientID* via JMX. > > I've attached the patch that extends the *ActiveMQServerControlImpl* and > *SessionView* classes to return the *clientID* if available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4754) Make configuring security for AMQP federation user accounts simpler
[ https://issues.apache.org/jira/browse/ARTEMIS-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842994#comment-17842994 ] ASF subversion and git services commented on ARTEMIS-4754: -- Commit d7a7116a4c31bdd830e66f54240b7204a83101ae in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=d7a7116a4c ] ARTEMIS-4754 Structure the names used for federation internal queues When creating internal temporary queues for the federation control links and the events link we should use a structured naming convention to ease in configuring security for the federation user where all internal names fall under a root prefix which can be used to grant read and write access for the federation user. This change allows security on the wildcarded address "$ACTIVEMQ_ARTEMIS_FEDERATION.#". This change also includes some further restrictions added to federation resources and adds support for wildcarding '$' prefixed addresses. > Make configuring security for AMQP federation user accounts simpler > --- > > Key: ARTEMIS-4754 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4754 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.34.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When creating the user account used to restrict access when securing an AMQP > federation account the currently implementation requires giving the > federation overly broad access so that it can create control and event queues > used for its internal mechanisms. We should make this easier and more narrow > so that a federation user can be granted access to a more limited set of > resources for internal federation mechanics besides access to those addresses > and queues which will be targets of federation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4752) Upgrade ErrorProne to 2.27.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842900#comment-17842900 ] ASF subversion and git services commented on ARTEMIS-4752: -- Commit 8b73335b464adf9cb79c762c0ca30910228a09db in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8b73335b46 ] ARTEMIS-4752 upgrade ErrorProne to 2.27.0 The upgraded ErrorProne found some new issues so this commit fixes those as well. > Upgrade ErrorProne to 2.27.0 > > > Key: ARTEMIS-4752 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4752 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9488) Upgrade to jackson 2.17.0
[ https://issues.apache.org/jira/browse/AMQ-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842874#comment-17842874 ] ASF subversion and git services commented on AMQ-9488: -- Commit b39e64f2582045b92f17a53e03000b0e63c27801 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=b39e64f25 ] Merge pull request #1212 from jbonofre/AMQ-9488 AMQ-9488: Upgrade to jackson 2.17.0 > Upgrade to jackson 2.17.0 > - > > Key: AMQ-9488 > URL: https://issues.apache.org/jira/browse/AMQ-9488 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Transport >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9488) Upgrade to jackson 2.17.0
[ https://issues.apache.org/jira/browse/AMQ-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842873#comment-17842873 ] ASF subversion and git services commented on AMQ-9488: -- Commit aa7c2377ccb46f06cf354363d0567faca497633c in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=aa7c2377c ] AMQ-9488: Upgrade to jackson 2.17.0 > Upgrade to jackson 2.17.0 > - > > Key: AMQ-9488 > URL: https://issues.apache.org/jira/browse/AMQ-9488 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Transport >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4750) AMQP Large Message flow control to use runAfter
[ https://issues.apache.org/jira/browse/ARTEMIS-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842729#comment-17842729 ] ASF subversion and git services commented on ARTEMIS-4750: -- Commit 14e83faa1bf5523d63755ec54f42cbc1d21affc6 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=14e83faa1b ] ARTEMIS-4750 AMQP Large Message flow control to use runAfter The resume delivery on AMQP Large Message Writer is using runNow. When a flow control is paused and then resumed, the runNow will make the first read to happen inline to the thread that's resuming other deliveries. It would be better to not run the delivery within the same call. Hence the change here is simple, being just using a connection.runLater instead of runNow. I have seen this on a thread dump from a production server. No semantic issues were encountered but there was a theory that the Netty thread responsible to resume would be busy with a delivery when not supposed to. Better to be safe on this case. > AMQP Large Message flow control to use runAfter > --- > > Key: ARTEMIS-4750 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4750 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > > the resume delivery on AMQP Large Message Writer is using runNow. > When a flow control is paused and then resumed, the runNow will make the > first read to happen inline to the thread that's resuming other deliveries. > It would be better to not run the delivery within the same call. Hence the > change here is simple, being just using a connection.runLater instead of > runNow. > I have seen this on a thread dump from a production server. > No semantic issues were encountered but there was a theory that the Netty > thread responsible to resume would be busy with a delivery when not supposed > to. Better to be safe on this case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9457) Add activemq-bom
[ https://issues.apache.org/jira/browse/AMQ-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842205#comment-17842205 ] ASF subversion and git services commented on AMQ-9457: -- Commit e116b5a47d158652bad1e8a3077511dd29d53e82 in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=e116b5a47 ] Merge branch 'mattrpav-AMQ-9457' > Add activemq-bom > > > Key: AMQ-9457 > URL: https://issues.apache.org/jira/browse/AMQ-9457 > Project: ActiveMQ Classic > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Fix For: 6.2.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Add an activemq-bom to assist in managing dependencies when using activemq > artifacts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9457) Add activemq-bom
[ https://issues.apache.org/jira/browse/AMQ-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842204#comment-17842204 ] ASF subversion and git services commented on AMQ-9457: -- Commit dc7c07e873f9e363907bd0f3c15751e9bf2fc119 in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=dc7c07e87 ] [AMQ-9457] Add activemq-bom-client > Add activemq-bom > > > Key: AMQ-9457 > URL: https://issues.apache.org/jira/browse/AMQ-9457 > Project: ActiveMQ Classic > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Fix For: 6.2.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Add an activemq-bom to assist in managing dependencies when using activemq > artifacts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9480) Update activemq-osgi import for Jetty 11
[ https://issues.apache.org/jira/browse/AMQ-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842198#comment-17842198 ] ASF subversion and git services commented on AMQ-9480: -- Commit 77ae81cbd88642f936363dde71f15f62ced7a03e in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=77ae81cbd ] [AMQ-9480] Update activemq-osgi import for Jetty 11 and 12 > Update activemq-osgi import for Jetty 11 > > > Key: AMQ-9480 > URL: https://issues.apache.org/jira/browse/AMQ-9480 > Project: ActiveMQ Classic > Issue Type: Task > Components: OSGi/Karaf >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9486) Upgrade Spring 6.1.6
[ https://issues.apache.org/jira/browse/AMQ-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842194#comment-17842194 ] ASF subversion and git services commented on AMQ-9486: -- Commit acf2ddd099645048aae4e7f5e8c2b4484ac5ee12 in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=acf2ddd09 ] [AMQ-9486] Upgrade Spring 6.1.6 > Upgrade Spring 6.1.6 > > > Key: AMQ-9486 > URL: https://issues.apache.org/jira/browse/AMQ-9486 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4746) SIMILAR_BRANCHES.SWITCH Identical branches in switch node
[
https://issues.apache.org/jira/browse/ARTEMIS-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841773#comment-17841773
]
ASF subversion and git services commented on ARTEMIS-4746:
--
Commit b50f01b02b4c829e7330980837629951eeafb304 in activemq-artemis's branch
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b50f01b02b ]
ARTEMIS-4746 Simplifying switch case on JMSExceptionHelper
> SIMILAR_BRANCHES.SWITCH Identical branches in switch node
> -
>
> Key: ARTEMIS-4746
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4746
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.33.0
>Reporter: Andrey Slepykh
>Assignee: Clebert Suconic
>Priority: Trivial
> Fix For: 2.34.0
>
> Attachments: Screenshot from 2024-04-28 17-46-07.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In [class JMSExceptionHelper|#L27]]
> In this stack of screenshots I show that there is unnecessary logic, by
> correcting which you can reduce the load on the computer and shorten the code
> !Screenshot from 2024-04-28 17-46-07.png!
> Some cases can be classified into groups, such as:
> a)
> # case CONNECTION_TIMEDOUT:
> 2. case INTERNAL_ERROR:
> 3. case NOT_CONNECTED:
> b)
> # {{case ILLEGAL_STATE:}}
> 2. {{{}case OBJECT_CLOSED{}}}{{{}:{}}}
> 3. {{case UNSUPPORTED_PACKET}}
> c)
> 1. {{case QUEUE_DOES_NOT_EXIST:}}
> 2. {{case QUEUE_EXISTS:}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1769) Return JMS Session's ClientID via JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841491#comment-17841491 ] ASF subversion and git services commented on ARTEMIS-1769: -- Commit 614b5cb32f8df9cd2824fdfe3b1e2cbdb44f2d6a in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=614b5cb32f ] ARTEMIS-1769 return JMS Session's ClientID via JMX > Return JMS Session's ClientID via JMX > - > > Key: ARTEMIS-1769 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1769 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Maxim Kalina >Assignee: Justin Bertram >Priority: Minor > Labels: patch > Attachments: return_jms_session's_clientID_via_JMX_if_exists.patch > > Time Spent: 20m > Remaining Estimate: 0h > > As discussed in the mailing list, currently there is no possibility to get > the JMS session's *clientID* via JMX. > > I've attached the patch that extends the *ActiveMQServerControlImpl* and > *SessionView* classes to return the *clientID* if available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4740) Reduce unnecessary boxing
[ https://issues.apache.org/jira/browse/ARTEMIS-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841489#comment-17841489 ] ASF subversion and git services commented on ARTEMIS-4740: -- Commit fc6f0ee9ec85ce4223296a195bc35899cbecb091 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fc6f0ee9ec ] ARTEMIS-4740 reduce unnecessary boxing > Reduce unnecessary boxing > - > > Key: ARTEMIS-4740 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4740 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841273#comment-17841273 ] ASF subversion and git services commented on ARTEMIS-4745: -- Commit 659b17c3a933a7d80f9148836d7b9bbd4275932f in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=659b17c3a9 ] ARTEMIS-4745 Allow configuration of the pull consumer batch size Allow for configuration of the batch size granted to the remote when an AMQP federation queue receiver is pulling messages only when there is local capacity to handle them. Some code housekeeping is done here to make adding future properties a bit simpler and require fewer changes. > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4744) AMQP broker connections don't fully support multi host URIs
[ https://issues.apache.org/jira/browse/ARTEMIS-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840888#comment-17840888 ] ASF subversion and git services commented on ARTEMIS-4744: -- Commit ee7a2c0944843bf8b3ebb939f5833aa26b1e1868 in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ee7a2c0944 ] ARTEMIS-4744 Fully support multple host broker connections URIs Create a new NettyConnector for each connection attempt that is configured from distinct broker connection URIs which allows for differing TLS configuration per remote connection configuration. > AMQP broker connections don't fully support multi host URIs > --- > > Key: ARTEMIS-4744 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4744 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When configuring a multi host connection URI for an AMQP broker connection > the connection will utilize some but not all of the configuration. The > broker will attempt connection to each host and port part specific on the URI > but does not apply configuration specific to a given host. This can lead to > failure on connect due to using the TLS configuration from the first host > when attempting to connect to the following N hosts. Users need to be able > to configure TLS specific options per host as values such as host > verification, SNI and trust stores can vary amongst hosts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4734) Null dereferencing in ReplicationManager.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840879#comment-17840879
]
ASF subversion and git services commented on ARTEMIS-4734:
--
Commit 934fe24e5c03f4801e8a3934cc02bbc10f0325ff in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=934fe24e5c ]
ARTEMIS-4734 mitigate NPE in ReplicationManager
> Null dereferencing in ReplicationManager.java
> -
>
> Key: ARTEMIS-4734
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4734
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{repliToken}} can be 0.
> In
> {{org.apache.activemq.artemis.core.replication.ReplicationManager#sendReplicatePacket(org.apache.activemq.artemis.core.protocol.core.Packet,
> boolean, org.apache.activemq.artemis.utils.ReusableLatch)}} the
> {{repliToken}} is initialized with the value returned by ([line
> 464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
> {{OperationContextImpl.getContext(ioExecutorFactory)}}, i.e.:
> {code:java}
> final OperationContext repliToken =
> OperationContextImpl.getContext(ioExecutorFactory);{code}
> Inside this method, a call is made to
> {{OperationContextImpl.threadLocalContext.get()}}([line
> 61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java]),
> which returns the value from the thread that was set earlier. If no value
> was set in the stream, then token will be {{null}}.
> {code:java}
> OperationContext token = OperationContextImpl.threadLocalContext.get();{code}
> If {{ioExecutorFactory}} is {{null}} and there is no value set in the thread,
> then the {{repliToken}} will remain {{null}} because the backing
> {{getContext()}} method also returns {{null}} in this case.
> So {{repliToken}} can be 0 if {{ioExecutorFactory}} is {{null}} and there is
> no value set in the thread.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840462#comment-17840462 ] ASF subversion and git services commented on ARTEMIS-4743: -- Commit 379515382e07dd7c1d6e6aa7bf69b163858a58f5 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=379515382e ] ARTEMIS-4743 Improve CLI Queue Stat Output: Split lines and include internal queue attribute > Improve CLI Queue Stat Output: Split lines and include internal queue > attribute > --- > > Key: ARTEMIS-4743 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4743 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840269#comment-17840269 ] ASF subversion and git services commented on ARTEMIS-4733: -- Commit 1e296021589ffa985d55a69e632e3408dafe762c in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1e29602158 ] ARTEMIS-4733 Fixing test as it is now correctly ignoring MQTT internal queue > Mirror Infinite loops (mirror infinite Reflection) from Internal Queues > --- > > Key: ARTEMIS-4733 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4733 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I am seeing Mirroring causing infinite reflections on createAddresses > I couldn't make the test I wrote to fail before ARTEMIS-4498 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4705) Remove unnecessary field from STOMP HeartBeater
[ https://issues.apache.org/jira/browse/ARTEMIS-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840256#comment-17840256 ] ASF subversion and git services commented on ARTEMIS-4705: -- Commit 61e52ae0fde45d53a068b752f3e5e4f4127876ba in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=61e52ae0fd ] ARTEMIS-4705 remove unnecessary field from STOMP HeartBeater > Remove unnecessary field from STOMP HeartBeater > --- > > Key: ARTEMIS-4705 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4705 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.25.0 >Reporter: Andrey Slepykh >Assignee: Justin Bertram >Priority: Major > Attachments: Screenshot from 2024-03-30 11-21-54.png > > Time Spent: 20m > Remaining Estimate: 0h > > line [266 > |https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/v11/StompFrameHandlerV11.java#L266] > declares the variable "shutdown" which is not used anywhere else, but takes > up memory > !Screenshot from 2024-03-30 11-21-54.png! > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author: Firsov Vladimir, BMSTU (fvv22u...@student.bmstu.ru) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade
[
https://issues.apache.org/jira/browse/ARTEMIS-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840038#comment-17840038
]
ASF subversion and git services commented on ARTEMIS-4742:
--
Commit f7288c16a6ceee6c314da2b372941d65057d8246 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f7288c16a6 ]
ARTEMIS-4742 decoding PersistedSecuritySetting fails after upgrade
> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have faced problem when upgrading one of ActiveMQ Artemis servers from
> 2.32.0 to 2.33.0.
> Artemis cannot start and writes an error to the log:
> {noformat}
> 2024-04-18 13:31:44,975 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation
> java.lang.IndexOutOfBoundsException: readerIndex(82) + length(1) exceeds
> writerIndex(82): UnpooledHeapByteBuf(ridx: 82, widx: 82, cap: 82/82)
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at
> org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:150)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:79)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.config.PersistedSecuritySetting.decode(PersistedSecuritySetting.java:255)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.newSecurityRecord(AbstractJournalStorageManager.java:2127)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.lambda$loadBindingJournal$5(AbstractJournalStorageManager.java:1640)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList$SparseArray.clear(SparseArrayLinkedList.java:114)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clearSparseArrayList(SparseArrayLinkedList.java:173)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clear(SparseArrayLinkedList.java:227)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1613)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3856)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3489)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ReplicationPrimaryActivation.run(ReplicationPrimaryActivation.java:145)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:738)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:628)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66)
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130)
> [artemis-cli-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:221)
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:167)
> [artemis-cli-2.33.0.jar:2.33.0]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> ~[?:?]
>
[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839799#comment-17839799 ] ASF subversion and git services commented on ARTEMIS-4733: -- Commit 86f7250d1c7a58f54d794e00aaa7a5067c8a951b in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=86f7250d1c ] ARTEMIS-4733 Fixing test as it is now correctly ignoring MQTT internal queue > Mirror Infinite loops (mirror infinite Reflection) from Internal Queues > --- > > Key: ARTEMIS-4733 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4733 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I am seeing Mirroring causing infinite reflections on createAddresses > I couldn't make the test I wrote to fail before ARTEMIS-4498 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis
[ https://issues.apache.org/jira/browse/ARTEMIS-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839740#comment-17839740 ] ASF subversion and git services commented on ARTEMIS-4709: -- Commit 20f345dbe18de05aabd80c1601113d2781a1c4a8 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=20f345dbe1 ] ARTEMIS-4709 plugin to enforce connection periodic expiry per acceptor > Add a plugin to provide periodic expiry of connections on a per acceptor basis > -- > > Key: ARTEMIS-4709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4709 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.34.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When credential rotation needs to be enforced, active connections need to be > terminated on some timeline to ensure credentials are reevaluated. There are > management apis that can be used but these require some intervention. > In addition to enforce some SLA around duration of connections, having an > easy way to limit connections to a given maximum period can be helpful. > A plugin that will be applied on an per acceptor basis, that can be used to > disconnect connections that have lived for some period can provide a nice > building block for these use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839732#comment-17839732
]
ASF subversion and git services commented on AMQ-9481:
--
Commit 827ad1012b934ca4fff749a5da1a9c1e070a0ee1 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=827ad1012 ]
AMQ-9481 - Correctly complete async servlet request on timeout
This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.
(cherry picked from commit 72befc14fbb69c24bdec0c7d4a1002da8874380d)
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839729#comment-17839729
]
ASF subversion and git services commented on AMQ-9481:
--
Commit 6e6caf7c6060efadc1ba524147e71d9720fcd935 in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=6e6caf7c6 ]
Merge pull request #1206 from apache/AMQ-9841
AMQ-9481 - Correctly complete async servlet request on timeout
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
> at
>
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839728#comment-17839728
]
ASF subversion and git services commented on AMQ-9481:
--
Commit 72befc14fbb69c24bdec0c7d4a1002da8874380d in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=72befc14f ]
AMQ-9481 - Correctly complete async servlet request on timeout
This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
>
[jira] [Commented] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839663#comment-17839663 ] ASF subversion and git services commented on ARTEMIS-4582: -- Commit a4d1f7084ddf2cafd339e4a236466e220039c8be in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a4d1f7084d ] ARTEMIS-4582 - fix typo in smoke test comment > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.33.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839470#comment-17839470 ] ASF subversion and git services commented on ARTEMIS-4733: -- Commit 44e78d42a22bdf7c59a22364d6c2d57de793b15a in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=44e78d42a2 ] ARTEMIS-4733 Internal queues should not be mirrored > Mirror Infinite loops (mirror infinite Reflection) from Internal Queues > --- > > Key: ARTEMIS-4733 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4733 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I am seeing Mirroring causing infinite reflections on createAddresses > I couldn't make the test I wrote to fail before ARTEMIS-4498 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher
[
https://issues.apache.org/jira/browse/AMQ-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839406#comment-17839406
]
ASF subversion and git services commented on AMQ-9481:
--
Commit 72befc14fbb69c24bdec0c7d4a1002da8874380d in activemq's branch
refs/heads/AMQ-9841 from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=72befc14f ]
AMQ-9481 - Correctly complete async servlet request on timeout
This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.
> Concurrent access error attempting to consume messages via REST API in 5.18.2
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
> Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>
> I am attempting to download a file from a queue via PowerShell. This can be
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer;
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times
> out after a short period if there are no files on the queue. When I run the
> same script against 5.18.2 or higher, I get the following error the first
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> + ~~~
> + CategoryInfo : InvalidOperation:
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
> eption
> + FullyQualifiedErrorId :
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException:
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException:
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
>
[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839249#comment-17839249 ] ASF subversion and git services commented on ARTEMIS-4733: -- Commit fdf2ea874bd903aba446d0bca377793028ed56b4 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fdf2ea874b ] ARTEMIS-4733 Infinite mirror reflections after CreateAddress > Mirror Infinite loops (mirror infinite Reflection) from Internal Queues > --- > > Key: ARTEMIS-4733 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4733 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I am seeing Mirroring causing infinite reflections on createAddresses > I couldn't make the test I wrote to fail before ARTEMIS-4498 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4727) Fix STOMP durable sub doc and property precedence
[ https://issues.apache.org/jira/browse/ARTEMIS-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839187#comment-17839187 ] ASF subversion and git services commented on ARTEMIS-4727: -- Commit ed59b0ea91e6238933143a9269d8dd80babf8e0a in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ed59b0ea91 ] ARTEMIS-4727 fix STOMP durable sub doc and property precedence > Fix STOMP durable sub doc and property precedence > - > > Key: ARTEMIS-4727 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4727 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The code and the documentation are incorrect regarding the precedence of the > STOMP frame headers used to identify the name of a durable subscription. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4731) Openwire failure detection leak with Windows Clients / Server won't cleanup openwork clients with Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839020#comment-17839020 ] ASF subversion and git services commented on ARTEMIS-4731: -- Commit 09dc4450717b169c651b978abccf40820acf33e3 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=09dc445071 ] ARTEMIS-4731 removing System.out left by accident > Openwire failure detection leak with Windows Clients / Server won't cleanup > openwork clients with Exception > --- > > Key: ARTEMIS-4731 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4731 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The OpenWireServerConnection won't deal properly with Exceptions raised by > Netty. > Windows clients will send a different signal to the server causing the > connection to throw an exception rather than issue a disconnect, > As a result some objects are being left on the heap as transport.close() is > not being called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4731) Openwire failure detection leak with Windows Clients / Server won't cleanup openwork clients with Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838855#comment-17838855 ] ASF subversion and git services commented on ARTEMIS-4731: -- Commit 6fe53b813a0e958b73ea3e703bad7b0c892e6044 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=6fe53b813a ] ARTEMIS-4731 OpenWireConnection exception listener should call transport.close(); this is causing a leak for server objects > Openwire failure detection leak with Windows Clients / Server won't cleanup > openwork clients with Exception > --- > > Key: ARTEMIS-4731 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4731 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The OpenWireServerConnection won't deal properly with Exceptions raised by > Netty. > Windows clients will send a different signal to the server causing the > connection to throw an exception rather than issue a disconnect, > As a result some objects are being left on the heap as transport.close() is > not being called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838770#comment-17838770 ] ASF subversion and git services commented on ARTEMIS-4723: -- Commit 69f68691574bb2d5f9c5b8f3fcf6ec4f1b0dc59d in activemq-artemis's branch refs/heads/openwire-fix from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=69f6869157 ] ARTEMIS-4723 Optimization on HandlerBase No need to create a new instance every time the processor starts executing. The instance of counter can be reused and stored in the Thread. > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1921) Setting client ID on core JMS should be reflected in broker RemotingConnection
[ https://issues.apache.org/jira/browse/ARTEMIS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838598#comment-17838598 ] ASF subversion and git services commented on ARTEMIS-1921: -- Commit 791630fa861f868beb3e2d778eb44f92117b0220 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=791630fa86 ] ARTEMIS-1921 setting client ID on core JMS should be reflected in broker RemotingConnection > Setting client ID on core JMS should be reflected in broker RemotingConnection > -- > > Key: ARTEMIS-1921 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1921 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.1 >Reporter: Johan Stenberg >Assignee: Justin Bertram >Priority: Major > Attachments: Artemis1921_CoreJmsClient_SetClientId_Test.java > > Time Spent: 20m > Remaining Estimate: 0h > > As opposite to Qpid JMS Client over AMPQ1.0 or FuseSource StompJMS client > over STOMP, a clientID set on the JMS ConnectionFactory or the Connection in > the Artemis JMS Client is not available on the broker via > RemotingConnection#getClientID(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838403#comment-17838403 ] ASF subversion and git services commented on ARTEMIS-4723: -- Commit 31243b10239184602a30749be8d83091e1e68c34 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=31243b1023 ] ARTEMIS-4723 Optimization on HandlerBase No need to create a new instance every time the processor starts executing. The instance of counter can be reused and stored in the Thread. > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838344#comment-17838344 ] ASF subversion and git services commented on ARTEMIS-4723: -- Commit e4a6687cd46421cf4fc89c3fa941f439772b6d29 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e4a6687cd4 ] ARTEMIS-4723 Avoid objects left on ThreadLocal from OrderedExecutorFactory co-authored: Jakob van Kruijssen > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4729) Upgrade slf4j version to 2.0.12
[ https://issues.apache.org/jira/browse/ARTEMIS-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838001#comment-17838001 ] ASF subversion and git services commented on ARTEMIS-4729: -- Commit f4581deb9dfa665b8a28c3f027ff7c71defca630 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f4581deb9d ] ARTEMIS-4729 Upgrade slf4j version to 2.0.12 > Upgrade slf4j version to 2.0.12 > --- > > Key: ARTEMIS-4729 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4729 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4728) Upgrade jgroups version to 5.3.4.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838000#comment-17838000 ] ASF subversion and git services commented on ARTEMIS-4728: -- Commit e065b4448fd03d573b34973044ba654b9212246b in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e065b4448f ] ARTEMIS-4728 Upgrade jgroups version to 5.3.4.Final > Upgrade jgroups version to 5.3.4.Final > -- > > Key: ARTEMIS-4728 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4728 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4725) Mirror may send wrong headers
[ https://issues.apache.org/jira/browse/ARTEMIS-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837926#comment-17837926 ] ASF subversion and git services commented on ARTEMIS-4725: -- Commit 8880ae92d9e3c3160bcc66e0028d29972db326ba in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8880ae92d9 ] ARTEMIS-4725 Fixing intermittent failure on test > Mirror may send wrong headers > - > > Key: ARTEMIS-4725 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4725 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > This is not specifically an issue in Mirroring or Broker Connection, but it > manifested as part of the broker connection codebase. > When a delivery for the first time after a reload happens, the delivery > annotation may be written before the header, breaking the specification. > Later on delivery the message, createDelieryCopy could get confused with the > positions: > https://github.com/apache/activemq-artemis/blob/50fae08b09a76e200ef107d06cc867231f644ccd/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L829 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4725) Mirror may send wrong headers
[ https://issues.apache.org/jira/browse/ARTEMIS-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837837#comment-17837837 ] ASF subversion and git services commented on ARTEMIS-4725: -- Commit 329d963717d5e73e22d181e251fae20fc5c73809 in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=329d963717 ] ARTEMIS-4725 Fix AMQP outgoing encoding if da encoded before header Fix the AMQP message scanning to account for the header not being at the front of the buffer which also accounts for odd case of broker storing message with delivery annotations ahead of the header. > Mirror may send wrong headers > - > > Key: ARTEMIS-4725 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4725 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > This is not specifically an issue in Mirroring or Broker Connection, but it > manifested as part of the broker connection codebase. > When a delivery for the first time after a reload happens, the delivery > annotation may be written before the header, breaking the specification. > Later on delivery the message, createDelieryCopy could get confused with the > positions: > https://github.com/apache/activemq-artemis/blob/50fae08b09a76e200ef107d06cc867231f644ccd/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L829 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4725) Mirror may send wrong headers
[ https://issues.apache.org/jira/browse/ARTEMIS-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837838#comment-17837838 ] ASF subversion and git services commented on ARTEMIS-4725: -- Commit eb7b0b09467c0395dbb5d628ccb93734feae1f5e in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=eb7b0b0946 ] ARTEMIS-4725 Mirroring tests using multiple versions > Mirror may send wrong headers > - > > Key: ARTEMIS-4725 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4725 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > This is not specifically an issue in Mirroring or Broker Connection, but it > manifested as part of the broker connection codebase. > When a delivery for the first time after a reload happens, the delivery > annotation may be written before the header, breaking the specification. > Later on delivery the message, createDelieryCopy could get confused with the > positions: > https://github.com/apache/activemq-artemis/blob/50fae08b09a76e200ef107d06cc867231f644ccd/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L829 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4625) Upgrade CheckStyle to 10.15.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837650#comment-17837650 ] ASF subversion and git services commented on ARTEMIS-4625: -- Commit 7072eb187ac4dea1a68414823e7b883a38ee319a in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7072eb187a ] ARTEMIS-4625 upgrade CheckStyle to 10.15.0 > Upgrade CheckStyle to 10.15.0 > - > > Key: ARTEMIS-4625 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4625 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1691) JMS Bridge: After the FailureHandler exits, a bridge cannot be started full functional anymore
[
https://issues.apache.org/jira/browse/ARTEMIS-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837504#comment-17837504
]
ASF subversion and git services commented on ARTEMIS-1691:
--
Commit a1db72395c055069439870ca147ebde6a0d16f44 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a1db72395c ]
ARTEMIS-1691 JMS bridge can't be manually restarted after failure
> JMS Bridge: After the FailureHandler exits, a bridge cannot be started full
> functional anymore
> --
>
> Key: ARTEMIS-1691
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1691
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: WildFly Servers.
>Reporter: Markus F
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h4. Setup
> JMSBridge on server a pulls messages from a remote server B.
> failureRetryInterval = 1 sec
> maxRetries = 1
> h4. To Reproduce
> Restart the remote server (need to take more than one second.)
> JMS Bridge prints out:
> {noformat}
> JMS Bridge unable to set up connections, bridge will be stopped{noformat}
> After the remote server is up again, start the bridge again.
> JMS Bridge prints out:
> {noformat}
> Started JMS Bridge testbridge{noformat}
> h4. Result:
> The bridge is started, but does still not consume messages.
> h4. Reason
> In {{JMSBridgeImpl}} line 1624, the failed boolean parameter is checked. It
> is not set to true anywhere outside the failure handlers ({{FailureHandler}}
> and {{StartupFailureHandler}}) or on initial adding of the bridge.
> But the {{FailureHandler}} has already exited. So the bridge will wait all
> time long for 500 ms in line 1626.
> h4. Solution
> I would add a
> {code:java}
> failed = false;{code}
> after line 403.
> I don't know how the release process is handled here, if I can make a pull
> request or something like that, I will do, if it is needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4724) Upgrade karaf version to 4.4.6
[ https://issues.apache.org/jira/browse/ARTEMIS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837263#comment-17837263 ] ASF subversion and git services commented on ARTEMIS-4724: -- Commit 021993fe7ccbd39936c2b6450a7e9d9a551ed9e2 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=021993fe7c ] ARTEMIS-4724 Upgrade karaf version to 4.4.6 > Upgrade karaf version to 4.4.6 > -- > > Key: ARTEMIS-4724 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4724 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837241#comment-17837241 ] ASF subversion and git services commented on ARTEMIS-4582: -- Commit 66caefe1d7309cf453f98dd1d048ebe0a3aaef28 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=66caefe1d7 ] ARTEMIS-4582 - fix missed change from update to view naming in the doc > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.33.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837231#comment-17837231 ] ASF subversion and git services commented on ARTEMIS-4582: -- Commit e43707aba953c4edc33e9370fa89526a5337e3f0 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e43707aba9 ] ARTEMIS-4582 - doc update to remove incorrect info > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.33.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836745#comment-17836745
]
ASF subversion and git services commented on ARTEMIS-1729:
--
Commit 66fcd7f4cf554a833d0fe3ee7760d2e083e01fca in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=66fcd7f4cf ]
ARTEMIS-1729 automatically check for broken documentation links
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
