[jira] [Work logged] (AMQ-9494) Upgrade to maven-source-plugin 3.3.1
[ https://issues.apache.org/jira/browse/AMQ-9494?focusedWorklogId=920864=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920864 ] ASF GitHub Bot logged work on AMQ-9494: --- Author: ASF GitHub Bot Created on: 25/May/24 05:45 Start Date: 25/May/24 05:45 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1224: URL: https://github.com/apache/activemq/pull/1224 Issue Time Tracking --- Worklog Id: (was: 920864) Time Spent: 20m (was: 10m) > Upgrade to maven-source-plugin 3.3.1 > > > Key: AMQ-9494 > URL: https://issues.apache.org/jira/browse/AMQ-9494 > 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] [Work logged] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?focusedWorklogId=920709=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920709 ] ASF GitHub Bot logged work on ARTEMIS-4726: --- Author: ASF GitHub Bot Created on: 23/May/24 17:56 Start Date: 23/May/24 17:56 Worklog Time Spent: 10m Work Description: jbertram merged PR #4943: URL: https://github.com/apache/activemq-artemis/pull/4943 Issue Time Tracking --- Worklog Id: (was: 920709) Time Spent: 50m (was: 40m) > 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] [Work logged] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?focusedWorklogId=920705=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920705 ] ASF GitHub Bot logged work on ARTEMIS-4726: --- Author: ASF GitHub Bot Created on: 23/May/24 16:55 Start Date: 23/May/24 16:55 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4943: URL: https://github.com/apache/activemq-artemis/pull/4943 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. Issue Time Tracking --- Worklog Id: (was: 920705) Time Spent: 40m (was: 0.5h) > 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: 40m > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920704=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920704 ] ASF GitHub Bot logged work on ARTEMIS-4771: --- Author: ASF GitHub Bot Created on: 23/May/24 16:43 Start Date: 23/May/24 16:43 Worklog Time Spent: 10m Work Description: gemmellr commented on PR #4932: URL: https://github.com/apache/activemq-artemis/pull/4932#issuecomment-2127615471 Replaced by #4942 Issue Time Tracking --- Worklog Id: (was: 920704) Time Spent: 3h 20m (was: 3h 10m) > 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 20m > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920703=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920703 ] ASF GitHub Bot logged work on ARTEMIS-4771: --- Author: ASF GitHub Bot Created on: 23/May/24 16:43 Start Date: 23/May/24 16:43 Worklog Time Spent: 10m Work Description: gemmellr closed pull request #4932: ARTEMIS-4771 Avoid NPE while delivering amqp large message after a close URL: https://github.com/apache/activemq-artemis/pull/4932 Issue Time Tracking --- Worklog Id: (was: 920703) Time Spent: 3h 10m (was: 3h) > 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 10m > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920702=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920702 ] ASF GitHub Bot logged work on ARTEMIS-4771: --- Author: ASF GitHub Bot Created on: 23/May/24 16:42 Start Date: 23/May/24 16:42 Worklog Time Spent: 10m Work Description: gemmellr merged PR #4942: URL: https://github.com/apache/activemq-artemis/pull/4942 Issue Time Tracking --- Worklog Id: (was: 920702) Time Spent: 3h (was: 2h 50m) > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920697=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920697
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 23/May/24 15:26
Start Date: 23/May/24 15:26
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4942:
URL: https://github.com/apache/activemq-artemis/pull/4942#discussion_r1611907602
##
artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriterTest.java:
##
@@ -0,0 +1,255 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.protocol.amqp.proton;
+
+import static org.junit.Assert.fail;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyInt;
+import static org.mockito.Mockito.atLeastOnce;
+import static org.mockito.Mockito.doAnswer;
+import static org.mockito.Mockito.verify;
+import static org.mockito.Mockito.verifyNoInteractions;
+import static org.mockito.Mockito.verifyNoMoreInteractions;
+import static org.mockito.Mockito.when;
+
+import org.apache.activemq.artemis.core.message.LargeBodyReader;
+import
org.apache.activemq.artemis.core.persistence.impl.nullpm.NullStorageManager;
+import org.apache.activemq.artemis.core.server.MessageReference;
+import org.apache.activemq.artemis.protocol.amqp.broker.AMQPLargeMessage;
+import org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback;
+import
org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection;
+import org.apache.activemq.artemis.spi.core.remoting.ReadyListener;
+import org.apache.qpid.proton.engine.Connection;
+import org.apache.qpid.proton.engine.Delivery;
+import org.apache.qpid.proton.engine.EndpointState;
+import org.apache.qpid.proton.engine.Sender;
+import org.apache.qpid.proton.engine.Session;
+import org.apache.qpid.proton.engine.impl.TransportImpl;
+import org.junit.Before;
+import org.junit.Test;
+import org.mockito.Mock;
+import org.mockito.Mockito;
+import org.mockito.MockitoAnnotations;
+import org.mockito.Spy;
+
+/**
+ * Tests for the AMQP Large Message Writer
+ */
+public class AMQPLargeMessageWriterTest {
+
+ @Mock
+ ProtonServerSenderContext serverSender;
+
+ @Mock
+ Sender protonSender;
+
+ @Mock
+ Session protonSession;
+
+ @Mock
+ Connection protonConnection;
+
+ @Mock
+ TransportImpl protonTransport;
+
+ @Mock
+ Delivery protonDelivery;
+
+ @Mock
+ MessageReference reference;
+
+ @Mock
+ AMQPLargeMessage message;
+
+ @Mock
+ LargeBodyReader bodyReader;
+
+ @Mock
+ AMQPConnectionContext connectionContext;
+
+ @Mock
+ AMQPSessionContext sessionContext;
+
+ @Mock
+ AMQPSessionCallback sessionSPI;
+
+ @Mock
+ org.apache.activemq.artemis.spi.core.remoting.Connection
transportConnection;
+
+ @Mock
+ ActiveMQProtonRemotingConnection remotingConnection;
+
+ @Spy
+ NullStorageManager nullStoreManager = new NullStorageManager();
+
+ @Before
+ public void setUp() {
+ MockitoAnnotations.openMocks(this);
+
+ when(serverSender.getSessionContext()).thenReturn(sessionContext);
+ when(serverSender.getSender()).thenReturn(protonSender);
+ when(serverSender.createDelivery(any(),
anyInt())).thenReturn(protonDelivery);
+
+ when(protonSender.getSession()).thenReturn(protonSession);
+ when(protonSession.getConnection()).thenReturn(protonConnection);
+ when(protonConnection.getTransport()).thenReturn(protonTransport);
+ when(protonTransport.getOutboundFrameSizeLimit()).thenReturn(65535);
+
+
when(transportConnection.getProtocolConnection()).thenReturn(remotingConnection);
+ when(reference.getMessage()).thenReturn(message);
+ when(message.isLargeMessage()).thenReturn(true);
+ when(message.getLargeBodyReader()).thenReturn(bodyReader);
+ when(sessionContext.getSessionSPI()).thenReturn(sessionSPI);
+
when(sessionContext.getAMQPConnectionContext()).thenReturn(connectionContext);
+
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920684=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920684 ] ASF GitHub Bot logged work on ARTEMIS-4771: --- Author: ASF GitHub Bot Created on: 23/May/24 15:03 Start Date: 23/May/24 15:03 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4942: URL: https://github.com/apache/activemq-artemis/pull/4942 …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. Issue Time Tracking --- Worklog Id: (was: 920684) Time Spent: 2h 40m (was: 2.5h) > 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: 2h 40m > 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] [Work logged] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?focusedWorklogId=920656=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920656
]
ASF GitHub Bot logged work on ARTEMIS-4777:
---
Author: ASF GitHub Bot
Created on: 23/May/24 13:16
Start Date: 23/May/24 13:16
Worklog Time Spent: 10m
Work Description: tabish121 closed pull request #4941: ARTEMIS-4777 Add
additional configuration for broker connection
URL: https://github.com/apache/activemq-artemis/pull/4941
Issue Time Tracking
---
Worklog Id: (was: 920656)
Time Spent: 0.5h (was: 20m)
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?focusedWorklogId=920605=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920605
]
ASF GitHub Bot logged work on ARTEMIS-4777:
---
Author: ASF GitHub Bot
Created on: 23/May/24 09:45
Start Date: 23/May/24 09:45
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4941:
URL: https://github.com/apache/activemq-artemis/pull/4941#discussion_r1611299971
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java:
##
@@ -701,7 +745,11 @@ private void connectSender(Queue queue,
sender.setSenderSettleMode(SenderSettleMode.UNSETTLED);
sender.setReceiverSettleMode(ReceiverSettleMode.FIRST);
Target target = new Target();
-target.setAddress(targetName);
+if (targetAddress != null && !targetAddress.isBlank()) {
+ target.setAddress(targetAddress);
Review Comment:
This targetName / targetAddress distinction is a bit awkard with both around
given that 'target address' is usually the normal terminology and what the
value actually sets. Perhaps change the prior one to targetAddress instead of
targetName, then use targetAddressOverride for the new 'use this instead' value
to clarify things?
Similarly for the receiver bit above.
EDIT: or see other comment, simplify this and move decision to the call site
where config is being pulled originally.
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -2228,6 +2228,50 @@
+
+
+
+
+
+
+ This address to assign to the AMQP sender link Target.
Review Comment:
This -> The? Similarly below.
Worth clarifying that this overrides the normal use of the queues associated
address as the target? Also that you probably dont typically want to use this
with a 'match' style configuration as every matched queue's associated sender
will then all send to the same target address? Should that config be prevented?
Maybe need some documentation around all this either way?
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java:
##
@@ -282,18 +285,52 @@ public void validateMatching(Queue queue,
AMQPBrokerConnectionElement connection
public void createLink(Queue queue, AMQPBrokerConnectionElement
connectionElement) {
if (connectionElement.getType() == AMQPBrokerConnectionAddressType.PEER)
{
Symbol[] dispatchCapability = new
Symbol[]{AMQPMirrorControllerSource.QPID_DISPATCH_WAYPOINT_CAPABILITY};
- connectSender(queue, queue.getAddress().toString(), null, null, null,
null, dispatchCapability, null);
- connectReceiver(protonRemotingConnection, session, sessionContext,
queue, dispatchCapability);
- } else {
- if (connectionElement.getType() ==
AMQPBrokerConnectionAddressType.SENDER) {
-connectSender(queue, queue.getAddress().toString(), null, null,
null, null, null, null);
+ connectSender(queue, queue.getAddress().toString(), null, null, null,
null, null, null, dispatchCapability);
+ connectReceiver(protonRemotingConnection, session, sessionContext,
queue, null, dispatchCapability);
+ } else if (connectionElement.getType() ==
AMQPBrokerConnectionAddressType.SENDER) {
+ String targetAddress = null;
+ Symbol[] targetCapabilities = null;
+
+ if (connectionElement instanceof AMQPSenderBrokerConnectionElement) {
+final AMQPSenderBrokerConnectionElement sender =
(AMQPSenderBrokerConnectionElement) connectionElement;
+
+targetAddress = sender.getTargetAddress();
+targetCapabilities =
parseTerminusCapabilities(sender.getTargetCapabilities());
}
- if (connectionElement.getType() ==
AMQPBrokerConnectionAddressType.RECEIVER) {
-connectReceiver(protonRemotingConnection, session, sessionContext,
queue);
+
+ connectSender(queue, queue.getAddress().toString(), null, null, null,
null, null, targetAddress, targetCapabilities);
Review Comment:
Could we actually just move the other 'is an explicit override address
defined' bit here, and then simply pass 'targetName' as before (perhaps renamed
to targetAddress though?), but which is then either the queues address as
originally, or the new configured 'override' target if defined? Would save
passing around 2 competing values for 1 thing and leave the other code simpler
/ as-is.
Similarly for the receiver bit below.
Issue Time Tracking
---
Worklog Id: (was: 920605)
Time Spent: 20m (was: 10m)
> Broker
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=920594=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920594 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 23/May/24 08:57 Start Date: 23/May/24 08:57 Worklog Time Spent: 10m Work Description: andytaylor opened a new pull request, #16: URL: https://github.com/apache/activemq-artemis-console/pull/16 upgrade yarn to 4.1.1 Issue Time Tracking --- Worklog Id: (was: 920594) Time Spent: 10h 50m (was: 10h 40m) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?focusedWorklogId=920486=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920486 ] ASF GitHub Bot logged work on ARTEMIS-4726: --- Author: ASF GitHub Bot Created on: 22/May/24 19:10 Start Date: 22/May/24 19:10 Worklog Time Spent: 10m Work Description: jbertram merged PR #4894: URL: https://github.com/apache/activemq-artemis/pull/4894 Issue Time Tracking --- Worklog Id: (was: 920486) Time Spent: 0.5h (was: 20m) > 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] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=920488=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920488 ] ASF GitHub Bot logged work on ARTEMIS-4768: --- Author: ASF GitHub Bot Created on: 22/May/24 19:10 Start Date: 22/May/24 19:10 Worklog Time Spent: 10m Work Description: jbertram merged PR #4929: URL: https://github.com/apache/activemq-artemis/pull/4929 Issue Time Tracking --- Worklog Id: (was: 920488) Time Spent: 50m (was: 40m) > 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] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920487=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920487
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 19:10
Start Date: 22/May/24 19:10
Worklog Time Spent: 10m
Work Description: jbertram merged PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897
Issue Time Tracking
---
Worklog Id: (was: 920487)
Time Spent: 1h 10m (was: 1h)
> 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] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920433=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920433
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 14:10
Start Date: 22/May/24 14:10
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897#discussion_r1610049746
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -219,6 +239,18 @@ public synchronized void start() throws Exception {
cleanupTmp();
server.start();
+ /*
Review Comment:
That's fair. Reverted.
Issue Time Tracking
---
Worklog Id: (was: 920433)
Time Spent: 1h (was: 50m)
> 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
> 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] [Work logged] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?focusedWorklogId=920414=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920414
]
ASF GitHub Bot logged work on ARTEMIS-4777:
---
Author: ASF GitHub Bot
Created on: 22/May/24 13:04
Start Date: 22/May/24 13:04
Worklog Time Spent: 10m
Work Description: tabish121 opened a new pull request, #4941:
URL: https://github.com/apache/activemq-artemis/pull/4941
Add additional configuration for the broker connection senders and receivers
that allows for setting the source or target address value and optional source
and target capabilities to allow providing address mapping on some remote peers.
Issue Time Tracking
---
Worklog Id: (was: 920414)
Remaining Estimate: 0h
Time Spent: 10m
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920378=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920378
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 09:10
Start Date: 22/May/24 09:10
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4897:
URL: https://github.com/apache/activemq-artemis/pull/4897#discussion_r1609588605
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -219,6 +239,18 @@ public synchronized void start() throws Exception {
cleanupTmp();
server.start();
+ /*
Review Comment:
I would revert this change.
the metrics call to jmx which is instrumented to audit, with out this filter
the audit on metrics will be less informative.
in addition, there are cases where access to metrics will need
authentication, especially when there is RBAC on JMX mbeans.
##
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java:
##
@@ -166,6 +173,19 @@ public synchronized void start() throws Exception {
handlers.addHandler(webContext);
webContext.setInitParameter(DIR_ALLOWED, "false");
webContext.getSessionHandler().getSessionCookieConfig().setComment("__SAME_SITE_STRICT__");
+ webContext.addEventListener(new ServletContextListener() {
+ @Override
+ public void contextInitialized(ServletContextEvent sce) {
+ sce.getServletContext().addListener(new
ServletRequestListener() {
+@Override
+public void requestDestroyed(ServletRequestEvent sre) {
+ ServletRequestListener.super.requestDestroyed(sre);
+ AuditLogger.currentCaller.remove();
Review Comment:
that looks right
Issue Time Tracking
---
Worklog Id: (was: 920378)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=920342=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920342
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 22/May/24 04:19
Start Date: 22/May/24 04:19
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4897:
URL:
https://github.com/apache/activemq-artemis/pull/4897#issuecomment-2123837290
@gtully, point taken. I've updated the PR with what I believe will address
the `ThreadLocal` issue. I wasn't able to come up with a way to test it
automatically, but manual tests (e.g. the use-case outlined in the Jira) is
working fine now.
Issue Time Tracking
---
Worklog Id: (was: 920342)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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] [Work logged] (ARTEMIS-4764) Increase automation for dependecy updates
[ https://issues.apache.org/jira/browse/ARTEMIS-4764?focusedWorklogId=920269=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920269 ] ASF GitHub Bot logged work on ARTEMIS-4764: --- Author: ASF GitHub Bot Created on: 21/May/24 16:33 Start Date: 21/May/24 16:33 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4925: URL: https://github.com/apache/activemq-artemis/pull/4925#issuecomment-2123014841 There will definitely be a bunch of PRs from dependabot as soon as this is merged. Waiting to merge until after 2.34.0 is reasonable. After the initial round of updates is done we should only see PRs as new dependencies are released. Issue Time Tracking --- Worklog Id: (was: 920269) Time Spent: 0.5h (was: 20m) > Increase automation for dependecy updates > - > > Key: ARTEMIS-4764 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4764 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > GitHub provides > [dependabot|https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates] > which, among other things, can automatically send PRs for Maven dependency > updates. This will eliminate much of the manual work. > However, the following manual steps will still be required to ensure proper > tracking: > * Create an associated Jira (the PR's title can be copy & pasted to the Jira) > * Update the PR branch so the dependabot commit references the Jira > That said, this is still a pretty big win in terms of overall automation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4764) Increase automation for dependecy updates
[ https://issues.apache.org/jira/browse/ARTEMIS-4764?focusedWorklogId=920267=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920267 ] ASF GitHub Bot logged work on ARTEMIS-4764: --- Author: ASF GitHub Bot Created on: 21/May/24 16:23 Start Date: 21/May/24 16:23 Worklog Time Spent: 10m Work Description: gemmellr commented on PR #4925: URL: https://github.com/apache/activemq-artemis/pull/4925#issuecomment-2122995622 Seems reasonable, but is presumably going to cause it to spam a bunch of PRs (10 at a time) initially for various stuff we arent on the latest for, e.g especially test deps, so I was thinking we should wait until after the already-delayed release. Issue Time Tracking --- Worklog Id: (was: 920267) Time Spent: 20m (was: 10m) > Increase automation for dependecy updates > - > > Key: ARTEMIS-4764 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4764 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > GitHub provides > [dependabot|https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates] > which, among other things, can automatically send PRs for Maven dependency > updates. This will eliminate much of the manual work. > However, the following manual steps will still be required to ensure proper > tracking: > * Create an associated Jira (the PR's title can be copy & pasted to the Jira) > * Update the PR branch so the dependabot commit references the Jira > That said, this is still a pretty big win in terms of overall automation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[
https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=920236=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920236
]
ASF GitHub Bot logged work on ARTEMIS-4768:
---
Author: ASF GitHub Bot
Created on: 21/May/24 14:39
Start Date: 21/May/24 14:39
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4929:
URL: https://github.com/apache/activemq-artemis/pull/4929#discussion_r1608454175
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/PostOfficeJournalLoader.java:
##
@@ -243,10 +243,6 @@ public void handleAddMessage(Map> queueMap) th
MessageReference ref = postOffice.reload(record.getMessage(),
queue, null);
ref.setDeliveryCount(record.getDeliveryCount());
-
- if (scheduledDeliveryTime != 0) {
- record.getMessage().setScheduledDeliveryTime(0L);
Review Comment:
@clebertsuconic, can you take another look at this before 2.34.0?
Issue Time Tracking
---
Worklog Id: (was: 920236)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=920227=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920227
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 21/May/24 14:15
Start Date: 21/May/24 14:15
Worklog Time Spent: 10m
Work Description: gemmellr merged PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909
Issue Time Tracking
---
Worklog Id: (was: 920227)
Time Spent: 1h (was: 50m)
> 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
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$137/0x000800e01dc8.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.1/ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.1/ThreadPoolExecutor.java:635)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> "Thread-24
>
[jira] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=920225=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920225
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 21/May/24 14:13
Start Date: 21/May/24 14:13
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909#discussion_r1608344664
##
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTConnectionManager.java:
##
@@ -176,33 +174,27 @@ ServerSessionImpl createServerSession(String username,
String password, String v
return (ServerSessionImpl) serverSession;
}
- void disconnect(boolean failure) {
+ synchronized void disconnect(boolean failure) {
if (session == null || session.getStopped()) {
return;
}
- synchronized (session.getState()) {
Review Comment:
I've looked through it carefully and I don't see any potential problems. The
relevant changes to the state are performed by `connect` and `disconnect` which
themselves now use `synchronized`.
Also, I can't find any other code that uses equivalent synchronization on
the state.
Issue Time Tracking
---
Worklog Id: (was: 920225)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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
>
[jira] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=920214=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920214
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 21/May/24 13:33
Start Date: 21/May/24 13:33
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909#discussion_r1608344664
##
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTConnectionManager.java:
##
@@ -176,33 +174,27 @@ ServerSessionImpl createServerSession(String username,
String password, String v
return (ServerSessionImpl) serverSession;
}
- void disconnect(boolean failure) {
+ synchronized void disconnect(boolean failure) {
if (session == null || session.getStopped()) {
return;
}
- synchronized (session.getState()) {
Review Comment:
I've looked through it carefully and I don't see any potential problems. The
relevant changes to the state are performed by `connect` and `disconnect` which
are themselves now use `synchronized`.
Issue Time Tracking
---
Worklog Id: (was: 920214)
Time Spent: 0.5h (was: 20m)
> 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: 0.5h
> 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
>
[jira] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=920215=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920215
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 21/May/24 13:33
Start Date: 21/May/24 13:33
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909#discussion_r1608344664
##
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTConnectionManager.java:
##
@@ -176,33 +174,27 @@ ServerSessionImpl createServerSession(String username,
String password, String v
return (ServerSessionImpl) serverSession;
}
- void disconnect(boolean failure) {
+ synchronized void disconnect(boolean failure) {
if (session == null || session.getStopped()) {
return;
}
- synchronized (session.getState()) {
Review Comment:
I've looked through it carefully and I don't see any potential problems. The
relevant changes to the state are performed by `connect` and `disconnect` which
themselves now use `synchronized`.
Issue Time Tracking
---
Worklog Id: (was: 920215)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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
>
[jira] [Work logged] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?focusedWorklogId=920095=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920095 ] ASF GitHub Bot logged work on ARTEMIS-4772: --- Author: ASF GitHub Bot Created on: 20/May/24 19:42 Start Date: 20/May/24 19:42 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4935: URL: https://github.com/apache/activemq-artemis/pull/4935#issuecomment-2121086774 Thanks for the contribution! I squashed the commits and cleaned up a few things during the merging process. Nice work! Issue Time Tracking --- Worklog Id: (was: 920095) Time Spent: 0.5h (was: 20m) > 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] [Work logged] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?focusedWorklogId=920091=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920091 ] ASF GitHub Bot logged work on ARTEMIS-4772: --- Author: ASF GitHub Bot Created on: 20/May/24 19:34 Start Date: 20/May/24 19:34 Worklog Time Spent: 10m Work Description: asfgit closed pull request #4935: ARTEMIS-4772 Expose registered broker plugin class names as JMX Attribute URL: https://github.com/apache/activemq-artemis/pull/4935 Issue Time Tracking --- Worklog Id: (was: 920091) Time Spent: 20m (was: 10m) > 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: 20m > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=920072=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-920072
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 20/May/24 16:17
Start Date: 20/May/24 16:17
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1606982803
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
I reviewed the existing code again and the Writer is still confined to the
connection thread unlike the modifications that moved some of the large message
reader off that thread. This would imply that a simple check on closed is
sufficient here as this case would just be an already scheduled run of this
writer that was behind the remote close handling.
Issue Time Tracking
---
Worklog Id: (was: 920072)
Time Spent: 2.5h (was: 2h 20m)
> 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: 2.5h
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919982=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919982
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 20/May/24 09:16
Start Date: 20/May/24 09:16
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1606489945
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
The close method is only safe to call on the connection thread, which is
where it appears to be being called. Are you seeing otherwise? If not there is
no benefit in introducing the 3 additional variables and complicating the code
with a huge if statement (might even mislead folks into thinking there is some
safety there isnt). Should be no need for synchronization as the writing code
is not called concurrently. It would seem its simply running from a previous
scheduling, but no longer needs to. If so that can be addressed by checking
'closed' at the start of the scheduled task if it was closed already before
proceeding.
Issue Time Tracking
---
Worklog Id: (was: 919982)
Time Spent: 2h 20m (was: 2h 10m)
> 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: 2h 20m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919965=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919965
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 20/May/24 02:29
Start Date: 20/May/24 02:29
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1606177252
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
@gemmellr the exception is a network disconnect. Client disconnects and a
network failure is transmitted. Close is called.
For that we need to either use a cached local variable or add
synchronization.
I suggest we add a local cache as it doesn't really matter if we just send
stuff on the already closed session. Adding synchronization on the write may
risk deadlocks.
I'm not able to fix it this week as I'm going out for a week. if you desire
to pick up this issue please close my PR and open a new one.
I will keep my as draft until I can come back into this.
Issue Time Tracking
---
Worklog Id: (was: 919965)
Time Spent: 2h 10m (was: 2h)
> 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: 2h 10m
> 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] [Work logged] (ARTEMIS-4776) Replicated Paged Files may leak as open on replica target
[ https://issues.apache.org/jira/browse/ARTEMIS-4776?focusedWorklogId=919964=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919964 ] ASF GitHub Bot logged work on ARTEMIS-4776: --- Author: ASF GitHub Bot Created on: 20/May/24 02:09 Start Date: 20/May/24 02:09 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4939: URL: https://github.com/apache/activemq-artemis/pull/4939 Issue Time Tracking --- Worklog Id: (was: 919964) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4776) Replicated Paged Files may leak as open on replica target
[ https://issues.apache.org/jira/browse/ARTEMIS-4776?focusedWorklogId=919963=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919963 ] ASF GitHub Bot logged work on ARTEMIS-4776: --- Author: ASF GitHub Bot Created on: 20/May/24 01:03 Start Date: 20/May/24 01:03 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4939: URL: https://github.com/apache/activemq-artemis/pull/4939 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 Issue Time Tracking --- Worklog Id: (was: 919963) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (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?focusedWorklogId=919867=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919867 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 17/May/24 15:33 Start Date: 17/May/24 15:33 Worklog Time Spent: 10m Work Description: gtully merged PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924 Issue Time Tracking --- Worklog Id: (was: 919867) Time Spent: 2h 20m (was: 2h 10m) > 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] [Work logged] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?focusedWorklogId=919844=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919844 ] ASF GitHub Bot logged work on ARTEMIS-4774: --- Author: ASF GitHub Bot Created on: 17/May/24 13:47 Start Date: 17/May/24 13:47 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4937: URL: https://github.com/apache/activemq-artemis/pull/4937 Issue Time Tracking --- Worklog Id: (was: 919844) Time Spent: 0.5h (was: 20m) > 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] [Work logged] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?focusedWorklogId=919843=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919843 ] ASF GitHub Bot logged work on ARTEMIS-4774: --- Author: ASF GitHub Bot Created on: 17/May/24 13:47 Start Date: 17/May/24 13:47 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4937: URL: https://github.com/apache/activemq-artemis/pull/4937#issuecomment-2117649346 I need to merge this PR. I have hours and hours of testing on this where I tweaked parameters.sh in multiple ways and the counters are always accurate. If there are minor issues or even tweaks that are needed to the code those could be addressed in a later PR.. .or feel free to send further commits on the branch. Issue Time Tracking --- Worklog Id: (was: 919843) Time Spent: 20m (was: 10m) > 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: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919710=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919710
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 16/May/24 15:27
Start Date: 16/May/24 15:27
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1603598360
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
ok.. I will make the change and add a test.
although the test is somewhat difficult as I think you need flowControl /
resume to make it happen.
although I could make a mockTest. If I can't reproduce it with a simple
consumer being closed I will create a mock test.
Issue Time Tracking
---
Worklog Id: (was: 919710)
Time Spent: 2h (was: 1h 50m)
> 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: 2h
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919692=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919692
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 16/May/24 13:01
Start Date: 16/May/24 13:01
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1603302310
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
If the code is being used as it was originally intended and only accessed
from one thread the check on closed state should be all that's needed yes.
Issue Time Tracking
---
Worklog Id: (was: 919692)
Time Spent: 1h 50m (was: 1h 40m)
> 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: 1h 50m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919655=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919655
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 16/May/24 08:59
Start Date: 16/May/24 08:59
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602912035
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
The message writer isnt thread safe overall and isnt really expected to be.
It looks like the close method is only accessed on the connection thread, same
as the writing methods. The closed variable looks to only be volatile due to
its other uses in checking writability of the sender from other threads.
Issue Time Tracking
---
Worklog Id: (was: 919655)
Time Spent: 1h 40m (was: 1.5h)
> 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: 1h 40m
> 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] [Work logged] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?focusedWorklogId=919624=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919624 ] ASF GitHub Bot logged work on ARTEMIS-4774: --- Author: ASF GitHub Bot Created on: 16/May/24 03:28 Start Date: 16/May/24 03:28 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4937: URL: https://github.com/apache/activemq-artemis/pull/4937 (no comment) Issue Time Tracking --- Worklog Id: (was: 919624) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919612=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919612
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:21
Start Date: 15/May/24 23:21
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602361845
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
I don't want to introduce any performance issue. I would prefer going safe.
Issue Time Tracking
---
Worklog Id: (was: 919612)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919610=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919610
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:17
Start Date: 15/May/24 23:17
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602358744
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
I don't see how not throwing an NPE due to thread synchronization issues
isn't best solved by proper thread synchronization...
With the current fix it could continue writing after the close if the close
is happening on another thread than the write as the values being checked
aren't synced on a barrier so they could be non-null for more than one
execution until a cache flush is forced by some other barrier. It might not NPE
now but it still isn't guaranteed to stop when you intended it to.
Issue Time Tracking
---
Worklog Id: (was: 919610)
Time Spent: 1h 20m (was: 1h 10m)
> 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: 1h 20m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919608=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919608
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:05
Start Date: 15/May/24 23:05
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602351080
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
The goal is to not Throw a npe. Not needed synchronization for that.
Issue Time Tracking
---
Worklog Id: (was: 919608)
Time Spent: 1h 10m (was: 1h)
> 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: 1h 10m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919607=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919607
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:02
Start Date: 15/May/24 23:02
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602349518
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
So why not just add synchronization if your goal is to make the code thread
safe?
Issue Time Tracking
---
Worklog Id: (was: 919607)
Time Spent: 1h (was: 50m)
> 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: 1h
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919605=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919605
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 22:10
Start Date: 15/May/24 22:10
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602306503
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
https://github.com/apache/activemq-artemis/blob/14e83faa1bf5523d63755ec54f42cbc1d21affc6/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java#L126-L134
so.. one thread is in resetClose.. another thread is on the tryDeliver...
closed is only set to true at the end of the statement...
as a result you could the NPE.
you may say set closed first...but still I don't feel like this is
completely atomic without added synchronization... however I don't want
synchrnoization here.. just a local copy and checking it should be enough for
me.
I plan to add a test on this.
Issue Time Tracking
---
Worklog Id: (was: 919605)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919604=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919604
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 22:08
Start Date: 15/May/24 22:08
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602304910
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
If I checked just closed, I guess you could still hit the NPE. You could
check the closed variable.. but I don't know how to get rid of the possible NPE
here without adding synchronization.
The NPE will be just an annoyance since it's closing anyway.. but I was
asked to mitigate the NPE.
Issue Time Tracking
---
Worklog Id: (was: 919604)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919579=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919579
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 18:22
Start Date: 15/May/24 18:22
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602074233
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
That would make more sense as the closed indicator is the only volatile in
the mix and would generally convey the state in a timely manner. Copying the
other resources local is fine but doesn't pass a barrier so they still aren't
the best indicator of closedness.
Issue Time Tracking
---
Worklog Id: (was: 919579)
Time Spent: 0.5h (was: 20m)
> 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: 0.5h
> 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] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=919576=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919576
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 15/May/24 17:37
Start Date: 15/May/24 17:37
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909#discussion_r1602019436
##
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTConnectionManager.java:
##
@@ -176,33 +174,27 @@ ServerSessionImpl createServerSession(String username,
String password, String v
return (ServerSessionImpl) serverSession;
}
- void disconnect(boolean failure) {
+ synchronized void disconnect(boolean failure) {
if (session == null || session.getStopped()) {
return;
}
- synchronized (session.getState()) {
Review Comment:
This seems fine in terms of protecting the connect+disconnect calls similar
to before...but, are there other areas synchronising on and accessing or
manipulating the session state that might no longer be protected as before that
still need to be?
Issue Time Tracking
---
Worklog Id: (was: 919576)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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
>
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919571=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919571
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 17:12
Start Date: 15/May/24 17:12
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1601973117
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
Cant we just check 'closed' here instead of all these changes and checks?
Issue Time Tracking
---
Worklog Id: (was: 919571)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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] [Work logged] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?focusedWorklogId=919533=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919533 ] ASF GitHub Bot logged work on ARTEMIS-4772: --- Author: ASF GitHub Bot Created on: 15/May/24 14:37 Start Date: 15/May/24 14:37 Worklog Time Spent: 10m Work Description: mnapierajAvSystem opened a new pull request, #4935: URL: https://github.com/apache/activemq-artemis/pull/4935 (no comment) Issue Time Tracking --- Worklog Id: (was: 919533) Remaining Estimate: 0h Time Spent: 10m > 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] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919531=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919531 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:32 Start Date: 15/May/24 14:32 Worklog Time Spent: 10m Work Description: mnapierajAvSystem closed pull request #4934: ARTEMIS-4745 Expose registered broker plugin class names as JMX Attribute URL: https://github.com/apache/activemq-artemis/pull/4934 Issue Time Tracking --- Worklog Id: (was: 919531) Time Spent: 1h 10m (was: 1h) > 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: 1h 10m > 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] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919530=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919530 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:19 Start Date: 15/May/24 14:19 Worklog Time Spent: 10m Work Description: mnapierajAvSystem commented on PR #4934: URL: https://github.com/apache/activemq-artemis/pull/4934#issuecomment-2112680407 you are absolutely right. Updating commit message will be enough or create a branch with proper name and new PR is required? Issue Time Tracking --- Worklog Id: (was: 919530) Time Spent: 1h (was: 50m) > 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: 1h > 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] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919527=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919527 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:15 Start Date: 15/May/24 14:15 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4934: URL: https://github.com/apache/activemq-artemis/pull/4934#issuecomment-2112671582 Seems as though you should be referencing [ARTEMIS-4772](https://issues.apache.org/jira/browse/ARTEMIS-4772) in this commit. Issue Time Tracking --- Worklog Id: (was: 919527) Time Spent: 50m (was: 40m) > 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: 50m > 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] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919525=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919525 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:10 Start Date: 15/May/24 14:10 Worklog Time Spent: 10m Work Description: mnapierajAvSystem opened a new pull request, #4934: URL: https://github.com/apache/activemq-artemis/pull/4934 (no comment) Issue Time Tracking --- Worklog Id: (was: 919525) Time Spent: 40m (was: 0.5h) > 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: 40m > 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] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=919470=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919470 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 15/May/24 10:13 Start Date: 15/May/24 10:13 Worklog Time Spent: 10m Work Description: gemmellr merged PR #15: URL: https://github.com/apache/activemq-artemis-console/pull/15 Issue Time Tracking --- Worklog Id: (was: 919470) Time Spent: 10h 40m (was: 10.5h) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10h 40m > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=919465=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919465 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 15/May/24 09:22 Start Date: 15/May/24 09:22 Worklog Time Spent: 10m Work Description: andytaylor commented on PR #15: URL: https://github.com/apache/activemq-artemis-console/pull/15#issuecomment-2112011157 > All looks good to me! Checking out this PR gave me the opportunity to run the hawtio console for the first time. > > Maybe it would be worth it to split the PR into a few commits though, I feel that there is space for at least one commit for the dependencies update and one commit for the UI fixes. I have split it into 2 commits as suggested Issue Time Tracking --- Worklog Id: (was: 919465) Time Spent: 10.5h (was: 10h 20m) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10.5h > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=919198=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919198
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 13/May/24 21:28
Start Date: 13/May/24 21:28
Worklog Time Spent: 10m
Work Description: Havret merged PR #37:
URL: https://github.com/apache/activemq-nms-openwire/pull/37
Issue Time Tracking
---
Worklog Id: (was: 919198)
Time Spent: 1.5h (was: 1h 20m)
> 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] [Work logged] (AMQ-9495) Upgrade to maven-assembly-plugin 3.7.1
[ https://issues.apache.org/jira/browse/AMQ-9495?focusedWorklogId=919128=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919128 ] ASF GitHub Bot logged work on AMQ-9495: --- Author: ASF GitHub Bot Created on: 13/May/24 14:43 Start Date: 13/May/24 14:43 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1225: URL: https://github.com/apache/activemq/pull/1225 (no comment) Issue Time Tracking --- Worklog Id: (was: 919128) Remaining Estimate: 0h Time Spent: 10m > Upgrade to maven-assembly-plugin 3.7.1 > -- > > Key: AMQ-9495 > URL: https://issues.apache.org/jira/browse/AMQ-9495 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9494) Upgrade to maven-source-plugin 3.3.1
[ https://issues.apache.org/jira/browse/AMQ-9494?focusedWorklogId=919119=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919119 ] ASF GitHub Bot logged work on AMQ-9494: --- Author: ASF GitHub Bot Created on: 13/May/24 14:20 Start Date: 13/May/24 14:20 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1224: URL: https://github.com/apache/activemq/pull/1224 (no comment) Issue Time Tracking --- Worklog Id: (was: 919119) Remaining Estimate: 0h Time Spent: 10m > Upgrade to maven-source-plugin 3.3.1 > > > Key: AMQ-9494 > URL: https://issues.apache.org/jira/browse/AMQ-9494 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9493) Upgrade to maven-plugin-plugin 3.12.0
[ https://issues.apache.org/jira/browse/AMQ-9493?focusedWorklogId=919118=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919118 ] ASF GitHub Bot logged work on AMQ-9493: --- Author: ASF GitHub Bot Created on: 13/May/24 14:19 Start Date: 13/May/24 14:19 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1223: URL: https://github.com/apache/activemq/pull/1223 (no comment) Issue Time Tracking --- Worklog Id: (was: 919118) Remaining Estimate: 0h Time Spent: 10m > Upgrade to maven-plugin-plugin 3.12.0 > - > > Key: AMQ-9493 > URL: https://issues.apache.org/jira/browse/AMQ-9493 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9490) Upgrade to commons-logging 1.3.1
[ https://issues.apache.org/jira/browse/AMQ-9490?focusedWorklogId=919113=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919113 ] ASF GitHub Bot logged work on AMQ-9490: --- Author: ASF GitHub Bot Created on: 13/May/24 14:11 Start Date: 13/May/24 14:11 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1214: URL: https://github.com/apache/activemq/pull/1214 Issue Time Tracking --- Worklog Id: (was: 919113) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[ https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919109=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919109 ] ASF GitHub Bot logged work on ARTEMIS-4771: --- Author: ASF GitHub Bot Created on: 13/May/24 13:39 Start Date: 13/May/24 13:39 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4932: URL: https://github.com/apache/activemq-artemis/pull/4932 (no comment) Issue Time Tracking --- Worklog Id: (was: 919109) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > 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] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=919070=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919070
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 13/May/24 11:58
Start Date: 13/May/24 11:58
Worklog Time Spent: 10m
Work Description: AndyDeMauriceGEDigital commented on code in PR #37:
URL:
https://github.com/apache/activemq-nms-openwire/pull/37#discussion_r1598352251
##
src/MessageConsumer.cs:
##
@@ -1251,15 +1251,11 @@ public virtual async Task
AfterMessageIsConsumedAsync(MessageDispatch dispatch,
}
else if(IsClientAcknowledge || IsIndividualAcknowledge)
{
-bool messageAckedByConsumer = false;
using(await this.deliveredMessagesLock.LockAsync().Await())
{
-messageAckedByConsumer =
this.deliveredMessages.Contains(dispatch);
-}
+if (this.deliveredMessages.Contains(dispatch))
Review Comment:
fixed
Issue Time Tracking
---
Worklog Id: (was: 919070)
Time Spent: 1h 20m (was: 1h 10m)
> 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: 1h 20m
> 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] [Work logged] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?focusedWorklogId=919037=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919037 ] ASF GitHub Bot logged work on AMQ-9498: --- Author: ASF GitHub Bot Created on: 13/May/24 09:00 Start Date: 13/May/24 09:00 Worklog Time Spent: 10m Work Description: kenliao94 closed pull request #1221: [AMQ-9498] Upgrade xbean-version to 4.25 URL: https://github.com/apache/activemq/pull/1221 Issue Time Tracking --- Worklog Id: (was: 919037) Time Spent: 20m (was: 10m) > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (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?focusedWorklogId=919036=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919036 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 13/May/24 08:50 Start Date: 13/May/24 08:50 Worklog Time Spent: 10m Work Description: gtully commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2107004581 thank you for all the feedback Issue Time Tracking --- Worklog Id: (was: 919036) Time Spent: 2h 10m (was: 2h) > 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 10m > 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] [Work logged] (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?focusedWorklogId=919035=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919035 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 13/May/24 08:49 Start Date: 13/May/24 08:49 Worklog Time Spent: 10m Work Description: gtully commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2107002721 > Looks good, have you run the full test suite on this set of changes? yes! Issue Time Tracking --- Worklog Id: (was: 919035) Time Spent: 2h (was: 1h 50m) > 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 > 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] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=918983=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918983
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 12/May/24 21:54
Start Date: 12/May/24 21:54
Worklog Time Spent: 10m
Work Description: Havret commented on code in PR #37:
URL:
https://github.com/apache/activemq-nms-openwire/pull/37#discussion_r1597722159
##
src/MessageConsumer.cs:
##
@@ -1251,15 +1251,11 @@ public virtual async Task
AfterMessageIsConsumedAsync(MessageDispatch dispatch,
}
else if(IsClientAcknowledge || IsIndividualAcknowledge)
{
-bool messageAckedByConsumer = false;
using(await this.deliveredMessagesLock.LockAsync().Await())
{
-messageAckedByConsumer =
this.deliveredMessages.Contains(dispatch);
-}
+if (this.deliveredMessages.Contains(dispatch))
Review Comment:
There is something messed up with the indentation here. Please add the
parentheses right below the 'if' so the intention is clear.
Issue Time Tracking
---
Worklog Id: (was: 918983)
Time Spent: 1h 10m (was: 1h)
> 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: 1h 10m
> 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] [Work logged] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?focusedWorklogId=918867=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918867 ] ASF GitHub Bot logged work on ARTEMIS-4743: --- Author: ASF GitHub Bot Created on: 10/May/24 21:03 Start Date: 10/May/24 21:03 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4931: URL: https://github.com/apache/activemq-artemis/pull/4931 Issue Time Tracking --- Worklog Id: (was: 918867) Time Spent: 3.5h (was: 3h 20m) > 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] [Work logged] (ARTEMIS-4743) Improve CLI Queue Stat Output: Split lines and include internal queue attribute
[ https://issues.apache.org/jira/browse/ARTEMIS-4743?focusedWorklogId=918803=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918803 ] ASF GitHub Bot logged work on ARTEMIS-4743: --- Author: ASF GitHub Bot Created on: 10/May/24 15:48 Start Date: 10/May/24 15:48 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4931: URL: https://github.com/apache/activemq-artemis/pull/4931 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. Issue Time Tracking --- Worklog Id: (was: 918803) Time Spent: 3h 20m (was: 3h 10m) > 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 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4770) Update to bouncycastle 1.78
[ https://issues.apache.org/jira/browse/ARTEMIS-4770?focusedWorklogId=918774=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918774 ] ASF GitHub Bot logged work on ARTEMIS-4770: --- Author: ASF GitHub Bot Created on: 10/May/24 13:53 Start Date: 10/May/24 13:53 Worklog Time Spent: 10m Work Description: asfgit closed pull request #4927: ARTEMIS-4770: Upgrade BouncyCastle to 1.78 URL: https://github.com/apache/activemq-artemis/pull/4927 Issue Time Tracking --- Worklog Id: (was: 918774) Remaining Estimate: 0h Time Spent: 10m > 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 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=918715=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918715 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 10/May/24 09:45 Start Date: 10/May/24 09:45 Worklog Time Spent: 10m Work Description: andytaylor opened a new pull request, #15: URL: https://github.com/apache/activemq-artemis-console/pull/15 Some general tidying up, adding ids and a few fixes Issue Time Tracking --- Worklog Id: (was: 918715) Time Spent: 10h 20m (was: 10h 10m) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918589=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918589 ] ASF GitHub Bot logged work on ARTEMIS-4765: --- Author: ASF GitHub Bot Created on: 09/May/24 19:02 Start Date: 09/May/24 19:02 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4928: URL: https://github.com/apache/activemq-artemis/pull/4928 Issue Time Tracking --- Worklog Id: (was: 918589) Time Spent: 1h (was: 50m) > 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] [Work logged] (ARTEMIS-4759) Restore compatibility with LiveOnlyPolicyConfiguration
[
https://issues.apache.org/jira/browse/ARTEMIS-4759?focusedWorklogId=918582=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918582
]
ASF GitHub Bot logged work on ARTEMIS-4759:
---
Author: ASF GitHub Bot
Created on: 09/May/24 18:03
Start Date: 09/May/24 18:03
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4922:
URL: https://github.com/apache/activemq-artemis/pull/4922
Issue Time Tracking
---
Worklog Id: (was: 918582)
Time Spent: 20m (was: 10m)
> 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] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[
https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918580=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918580
]
ASF GitHub Bot logged work on ARTEMIS-4765:
---
Author: ASF GitHub Bot
Created on: 09/May/24 17:30
Start Date: 09/May/24 17:30
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4928:
URL: https://github.com/apache/activemq-artemis/pull/4928#discussion_r1595763408
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java:
##
@@ -1467,6 +1476,22 @@ public DuplicateIDCache getDuplicateIDCache(final
SimpleString address, int cach
return cache;
}
+ private void registerCacheSize(SimpleString address, int cacheSizeToUse) {
+ AbstractPersistedAddressSetting recordedSetting =
storageManager.recoverAddressSettings(address);
+ if (recordedSetting == null ||
recordedSetting.getSetting().getIDCacheSize() == null ||
recordedSetting.getSetting().getIDCacheSize().intValue() != cacheSizeToUse) {
+ AddressSettings settings = recordedSetting != null ?
recordedSetting.getSetting() : new AddressSettings();
+ settings.setIDCacheSize(cacheSizeToUse);
+ server.getAddressSettingsRepository().addMatch(address.toString(),
settings);
+ try {
+storageManager.storeAddressSetting(new
PersistedAddressSettingJSON(address, settings, settings.toJSON()));
+ } catch (Exception e) {
+// nothing could be done here, we just log
+// if an exception is happening, if IO is compromised the server
will eventually shutdown
+logger.warn(e.getMessage(), e);
Review Comment:
I'm adding a loggerID.. thanks
Issue Time Tracking
---
Worklog Id: (was: 918580)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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] [Work logged] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?focusedWorklogId=918552=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918552
]
ASF GitHub Bot logged work on ARTEMIS-4420:
---
Author: ASF GitHub Bot
Created on: 09/May/24 14:29
Start Date: 09/May/24 14:29
Worklog Time Spent: 10m
Work Description: gtully commented on PR #4897:
URL:
https://github.com/apache/activemq-artemis/pull/4897#issuecomment-2102777907
Using a thread local to propagate the session subject is fine, but it needs
to be scoped to the user of that thread for the request, and cleared on
response. so set every time.
Issue Time Tracking
---
Worklog Id: (was: 918552)
Time Spent: 0.5h (was: 20m)
> 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: 0.5h
> 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] [Work logged] (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?focusedWorklogId=918527=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918527 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 09/May/24 12:08 Start Date: 09/May/24 12:08 Worklog Time Spent: 10m Work Description: gtully commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2102540122 > I agree w/ @cshannon here. There should be a setting to support honoring a valid list of package names Issue Time Tracking --- Worklog Id: (was: 918527) Time Spent: 1h 50m (was: 1h 40m) > 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: 1h 50m > 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] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[
https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918525=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918525
]
ASF GitHub Bot logged work on ARTEMIS-4765:
---
Author: ASF GitHub Bot
Created on: 09/May/24 11:29
Start Date: 09/May/24 11:29
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4928:
URL: https://github.com/apache/activemq-artemis/pull/4928#discussion_r1595327380
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java:
##
@@ -1467,6 +1476,22 @@ public DuplicateIDCache getDuplicateIDCache(final
SimpleString address, int cach
return cache;
}
+ private void registerCacheSize(SimpleString address, int cacheSizeToUse) {
+ AbstractPersistedAddressSetting recordedSetting =
storageManager.recoverAddressSettings(address);
+ if (recordedSetting == null ||
recordedSetting.getSetting().getIDCacheSize() == null ||
recordedSetting.getSetting().getIDCacheSize().intValue() != cacheSizeToUse) {
+ AddressSettings settings = recordedSetting != null ?
recordedSetting.getSetting() : new AddressSettings();
+ settings.setIDCacheSize(cacheSizeToUse);
+ server.getAddressSettingsRepository().addMatch(address.toString(),
settings);
+ try {
+storageManager.storeAddressSetting(new
PersistedAddressSettingJSON(address, settings, settings.toJSON()));
+ } catch (Exception e) {
+// nothing could be done here, we just log
+// if an exception is happening, if IO is compromised the server
will eventually shutdown
+logger.warn(e.getMessage(), e);
Review Comment:
better say what the context here is, "error storing an address setting,
reason: " + e.getMessage()
Issue Time Tracking
---
Worklog Id: (was: 918525)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[
https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=918469=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918469
]
ASF GitHub Bot logged work on ARTEMIS-4768:
---
Author: ASF GitHub Bot
Created on: 09/May/24 03:22
Start Date: 09/May/24 03:22
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4929:
URL: https://github.com/apache/activemq-artemis/pull/4929#discussion_r1594918161
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/PostOfficeJournalLoader.java:
##
@@ -243,10 +243,6 @@ public void handleAddMessage(Map> queueMap) th
MessageReference ref = postOffice.reload(record.getMessage(),
queue, null);
ref.setDeliveryCount(record.getDeliveryCount());
-
- if (scheduledDeliveryTime != 0) {
- record.getMessage().setScheduledDeliveryTime(0L);
Review Comment:
If you look a few lines up from the code I removed you'll see this:
```java
if (scheduledDeliveryTime != 0) {
record.getMessage().setScheduledDeliveryTime(scheduledDeliveryTime);
}
```
So first we set it to `scheduledDeliveryTime` and then we set it to `0`. One
of these must be wrong. I believe the one I removed in the wrong one.
There is another block still further up that does this:
```java
if (scheduledDeliveryTime != 0 && scheduledDeliveryTime <= currentTime) {
scheduledDeliveryTime = 0;
record.getMessage().setScheduledDeliveryTime(0L);
}
```
Reloading a message _whose scheduled delivery time is already passed_ should
not be scheduled. Is this what you were referring to?
Issue Time Tracking
---
Worklog Id: (was: 918469)
Time Spent: 0.5h (was: 20m)
> 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: 0.5h
> 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] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[
https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=918432=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918432
]
ASF GitHub Bot logged work on ARTEMIS-4768:
---
Author: ASF GitHub Bot
Created on: 08/May/24 22:45
Start Date: 08/May/24 22:45
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4929:
URL: https://github.com/apache/activemq-artemis/pull/4929#discussion_r1594778725
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/PostOfficeJournalLoader.java:
##
@@ -243,10 +243,6 @@ public void handleAddMessage(Map> queueMap) th
MessageReference ref = postOffice.reload(record.getMessage(),
queue, null);
ref.setDeliveryCount(record.getDeliveryCount());
-
- if (scheduledDeliveryTime != 0) {
- record.getMessage().setScheduledDeliveryTime(0L);
Review Comment:
I think this was on purpose. If you are reloading it it shouldn't be
scheduled.
Issue Time Tracking
---
Worklog Id: (was: 918432)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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] [Work logged] (ARTEMIS-4768) Property _AMQ_SCHED_DELIVERY lost from Scheduled Persistent Message after broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-4768?focusedWorklogId=918429=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918429 ] ASF GitHub Bot logged work on ARTEMIS-4768: --- Author: ASF GitHub Bot Created on: 08/May/24 22:23 Start Date: 08/May/24 22:23 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4929: URL: https://github.com/apache/activemq-artemis/pull/4929 (no comment) Issue Time Tracking --- Worklog Id: (was: 918429) Remaining Estimate: 0h Time Spent: 10m > 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 >Priority: Major > Time Spent: 10m > 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] [Work logged] (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?focusedWorklogId=918417=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918417 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 20:09 Start Date: 08/May/24 20:09 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2101343221 I agree w/ @cshannon here. There should be a setting to support honoring a valid list of package names Issue Time Tracking --- Worklog Id: (was: 918417) Time Spent: 1h 40m (was: 1.5h) > 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: 1h 40m > 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] [Work logged] (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?focusedWorklogId=918410=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918410 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 19:40 Start Date: 08/May/24 19:40 Worklog Time Spent: 10m Work Description: cshannon commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2101300102 > I have opened https://issues.apache.org/jira/browse/ARTEMIS-4766 to follow up. In regards to a follow up...my opinion is the validation should be done now and not as a follow and included as part of this change. Creating Jiras often leads to things just getting forgotten about and never done and I think this is important enough to not just put it off for later. Matt makes a good point about defense in depth and after thinking about it I would be -1 on this PR without adding some way to validate the class type now. There's been way too many CVEs that have popped up that involve class loading and serialization so no reason to risk it. Issue Time Tracking --- Worklog Id: (was: 918410) Time Spent: 1.5h (was: 1h 20m) > 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: 1.5h > 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] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918391=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918391 ] ASF GitHub Bot logged work on ARTEMIS-4765: --- Author: ASF GitHub Bot Created on: 08/May/24 17:03 Start Date: 08/May/24 17:03 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4928: URL: https://github.com/apache/activemq-artemis/pull/4928 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. Issue Time Tracking --- Worklog Id: (was: 918391) Time Spent: 0.5h (was: 20m) > 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: 0.5h > 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] [Work logged] (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?focusedWorklogId=918303=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918303 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 11:56 Start Date: 08/May/24 11:56 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2100411588 There is a value in defense in depth. Attackers are scanning source code trees looking for unprotected deserialization and then crafting entry points. While the config is stored on a filesystem out of the box —- in the wild files become ConfigMaps, mounts become network mounts, config files are stored in scm, or other CI/CD tool chain, etc etc. Issue Time Tracking --- Worklog Id: (was: 918303) Time Spent: 1h 20m (was: 1h 10m) > 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: 1h 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] [Work logged] (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?focusedWorklogId=918300=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918300 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 11:35 Start Date: 08/May/24 11:35 Worklog Time Spent: 10m Work Description: cshannon commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2100376697 @gtully - You are right that it may not help much in this case since it's server side config and if you have access to the file system to modify jars on the classpath or update the config you have already it's likely too late. This is different than the OpenWire CVE where a client could send in the malicious command so they did not need access. I figured it was still worth bringing it up for discussion as I still think it's a good idea to play it safer and make it a bit more strict. There are also 2 other nice things about adding a new interface and requiring a type besides security reasons that I think make it worthwhile. 1. This makes validation a bit easier as requiring a specific type is a quick way to make sure someone didn't screw up the configuration and that the class used was intended. 2. If desired, it allows requiring the implementations provide certain behavior by adding method signatures to the interface. This may not be required in this case but it's nice to have that option. Issue Time Tracking --- Worklog Id: (was: 918300) Time Spent: 1h 10m (was: 1h) > 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: 1h 10m > 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] [Work logged] (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?focusedWorklogId=918292=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918292 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 10:34 Start Date: 08/May/24 10:34 Worklog Time Spent: 10m Work Description: gtully commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2100274268 I have opened https://issues.apache.org/jira/browse/ARTEMIS-4766 to follow up. Issue Time Tracking --- Worklog Id: (was: 918292) Time Spent: 1h (was: 50m) > 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: 1h > 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] [Work logged] (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?focusedWorklogId=918290=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918290 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 08/May/24 10:25 Start Date: 08/May/24 10:25 Worklog Time Spent: 10m Work Description: gtully commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2100259018 I don't know that it helps, the values in question come from configuration. We have no choice but to trust configuration, i.e: the file system, where our sources live. These are exiting extension points, where the config provides the implementation. Any malicious intervention will implement any required interface if that is enforced. Any allow list gate will have to be configured in some way, probably on the file system. For an existing gadget to be exploited via this mechanism, the config has to be compromised, which is the file system, on that same file system can be any jar etc... so anything we do can be compromised unless we go down the route of signed jars etc. even then if the file system is compromised in short, I am not convinced of an interface check being of any great value when the threat is from file system compromise. Having said that, if there is value in the additional check, and I guess the value is that it makes it a little harder (if that makes any difference) it would need to be done before every newInstance of this sort to be effective. The xml parser does the same thing for one, in support of the same use case. Again, it is trusting config. Issue Time Tracking --- Worklog Id: (was: 918290) Time Spent: 50m (was: 40m) > 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: 50m > 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] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918218=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918218 ] ASF GitHub Bot logged work on ARTEMIS-4765: --- Author: ASF GitHub Bot Created on: 08/May/24 00:42 Start Date: 08/May/24 00:42 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4926: URL: https://github.com/apache/activemq-artemis/pull/4926 Issue Time Tracking --- Worklog Id: (was: 918218) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4765) Target Mirror is setting wrong size on duplicate cache
[ https://issues.apache.org/jira/browse/ARTEMIS-4765?focusedWorklogId=918205=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918205 ] ASF GitHub Bot logged work on ARTEMIS-4765: --- Author: ASF GitHub Bot Created on: 07/May/24 22:57 Start Date: 07/May/24 22:57 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4926: URL: https://github.com/apache/activemq-artemis/pull/4926 (no comment) Issue Time Tracking --- Worklog Id: (was: 918205) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > 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] [Work logged] (ARTEMIS-4764) Increase automation for dependecy updates
[ https://issues.apache.org/jira/browse/ARTEMIS-4764?focusedWorklogId=918173=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918173 ] ASF GitHub Bot logged work on ARTEMIS-4764: --- Author: ASF GitHub Bot Created on: 07/May/24 19:37 Start Date: 07/May/24 19:37 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4925: URL: https://github.com/apache/activemq-artemis/pull/4925 (no comment) Issue Time Tracking --- Worklog Id: (was: 918173) Remaining Estimate: 0h Time Spent: 10m > Increase automation for dependecy updates > - > > Key: ARTEMIS-4764 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4764 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > GitHub provides > [dependabot|https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates] > which, among other things, can automatically send PRs for Maven dependency > updates. This will eliminate much of the manual work. > However, the following manual steps will still be required to ensure proper > tracking: > * Create an associated Jira (the PR's title can be copy & pasted to the Jira) > * Update the PR branch so the dependabot commit references the Jira > That said, this is still a pretty big win in terms of overall automation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (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?focusedWorklogId=918170=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918170 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 07/May/24 19:34 Start Date: 07/May/24 19:34 Worklog Time Spent: 10m Work Description: cshannon commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2099159700 > In general we have learned through a number of security reports that blindly creating any class instance is usually not the greatest idea. It would be beneficial to at least scope the class created to an instance of an expected type, the test seems to be creating Transformer types to validating that before newInstance somehow would be beneficial. The other big one that seems to pop up a lot is java serialization CVEs, basically the same issue... allowing instantiation of Java objects without validation that the type isn't something malicious Issue Time Tracking --- Worklog Id: (was: 918170) Time Spent: 40m (was: 0.5h) > 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: 40m > 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] [Work logged] (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?focusedWorklogId=918167=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918167 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 07/May/24 18:58 Start Date: 07/May/24 18:58 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2099105340 > Does this need to have validation on allowed class types added? Just wondering if there are any potential security concerns like we recently had with the OpenWire protocol not validating class types. In general we have learned through a number of security reports that blindly creating any class instance is usually not the greatest idea. It would be beneficial to at least scope the class created to an instance of an expected type, the test seems to be creating Transformer types to validating that before newInstance somehow would be beneficial. Issue Time Tracking --- Worklog Id: (was: 918167) Time Spent: 0.5h (was: 20m) > 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: 0.5h > 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] [Work logged] (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?focusedWorklogId=918144=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918144 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 07/May/24 17:24 Start Date: 07/May/24 17:24 Worklog Time Spent: 10m Work Description: cshannon commented on PR #4924: URL: https://github.com/apache/activemq-artemis/pull/4924#issuecomment-2098949647 Does this need to have validation on allowed class types added? Just wondering if there are any potential security concerns like we recently had with the OpenWire protocol not validating class types. Issue Time Tracking --- Worklog Id: (was: 918144) Time Spent: 20m (was: 10m) > 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: 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] [Work logged] (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?focusedWorklogId=918109=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918109 ] ASF GitHub Bot logged work on ARTEMIS-4763: --- Author: ASF GitHub Bot Created on: 07/May/24 14:21 Start Date: 07/May/24 14:21 Worklog Time Spent: 10m Work Description: gtully opened a new pull request, #4924: URL: https://github.com/apache/activemq-artemis/pull/4924 …ies config of metrics plugins Issue Time Tracking --- Worklog Id: (was: 918109) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > 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] [Work logged] (ARTEMIS-4762) Queue Stat throw NPE if executed against old server
[ https://issues.apache.org/jira/browse/ARTEMIS-4762?focusedWorklogId=917940=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917940 ] ASF GitHub Bot logged work on ARTEMIS-4762: --- Author: ASF GitHub Bot Created on: 06/May/24 20:56 Start Date: 06/May/24 20:56 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4923: URL: https://github.com/apache/activemq-artemis/pull/4923 Issue Time Tracking --- Worklog Id: (was: 917940) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4762) Queue Stat throw NPE if executed against old server
[ https://issues.apache.org/jira/browse/ARTEMIS-4762?focusedWorklogId=917908=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917908 ] ASF GitHub Bot logged work on ARTEMIS-4762: --- Author: ASF GitHub Bot Created on: 06/May/24 19:10 Start Date: 06/May/24 19:10 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4923: URL: https://github.com/apache/activemq-artemis/pull/4923 (no comment) Issue Time Tracking --- Worklog Id: (was: 917908) Remaining Estimate: 0h Time Spent: 10m > 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: 10m > Remaining Estimate: 0h > > Start 2.28 server, and run ./artemis queue stat against that server. > You will get a NullPointerException or a JSON exception: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4755) Upgrade Jackson to 2.17.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4755?focusedWorklogId=917892=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917892 ] ASF GitHub Bot logged work on ARTEMIS-4755: --- Author: ASF GitHub Bot Created on: 06/May/24 18:26 Start Date: 06/May/24 18:26 Worklog Time Spent: 10m Work Description: jbertram merged PR #4913: URL: https://github.com/apache/activemq-artemis/pull/4913 Issue Time Tracking --- Worklog Id: (was: 917892) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4751) Upgrade to Apache parent 32
[ https://issues.apache.org/jira/browse/ARTEMIS-4751?focusedWorklogId=917893=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917893 ] ASF GitHub Bot logged work on ARTEMIS-4751: --- Author: ASF GitHub Bot Created on: 06/May/24 18:26 Start Date: 06/May/24 18:26 Worklog Time Spent: 10m Work Description: jbertram merged PR #4911: URL: https://github.com/apache/activemq-artemis/pull/4911 Issue Time Tracking --- Worklog Id: (was: 917893) Time Spent: 1h (was: 50m) > 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] [Work logged] (ARTEMIS-4753) Upgrade CheckStyle to 10.16.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4753?focusedWorklogId=917891=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917891 ] ASF GitHub Bot logged work on ARTEMIS-4753: --- Author: ASF GitHub Bot Created on: 06/May/24 18:26 Start Date: 06/May/24 18:26 Worklog Time Spent: 10m Work Description: jbertram merged PR #4914: URL: https://github.com/apache/activemq-artemis/pull/4914 Issue Time Tracking --- Worklog Id: (was: 917891) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4756) Upgrade Commons IO to 2.16.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4756?focusedWorklogId=917890=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917890 ] ASF GitHub Bot logged work on ARTEMIS-4756: --- Author: ASF GitHub Bot Created on: 06/May/24 18:25 Start Date: 06/May/24 18:25 Worklog Time Spent: 10m Work Description: jbertram merged PR #4915: URL: https://github.com/apache/activemq-artemis/pull/4915 Issue Time Tracking --- Worklog Id: (was: 917890) Time Spent: 20m (was: 10m) > 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] [Work logged] (ARTEMIS-4757) Upgrade Netty to 4.1.109.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4757?focusedWorklogId=917889=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-917889 ] ASF GitHub Bot logged work on ARTEMIS-4757: --- Author: ASF GitHub Bot Created on: 06/May/24 18:25 Start Date: 06/May/24 18:25 Worklog Time Spent: 10m Work Description: jbertram merged PR #4917: URL: https://github.com/apache/activemq-artemis/pull/4917 Issue Time Tracking --- Worklog Id: (was: 917889) Time Spent: 20m (was: 10m) > 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)
