[jira] [Comment Edited] (ARTEMIS-5042) The load balancing is not working correctly when several brokers are down
[
https://issues.apache.org/jira/browse/ARTEMIS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883311#comment-17883311
]
Justin Bertram edited comment on ARTEMIS-5042 at 9/20/24 8:12 PM:
--
I believe the problem is being caused by this exception which is being thrown
and short-circuiting the removal of the cluster bridge flow record (resulting
in messages still being routed to the bridge's store-and-forward queue):
{noformat}
2024-09-20 10:34:50,998 WARN [org.apache.activemq.artemis.core.server]
AMQ68: Failed to remove a record
java.lang.IllegalStateException: Cannot find binding
mtmccon_ucpmula_sms_193#mcla_simusmsc3_ucpmula_queue9eb3fb16-71d6-11ef-9298-506b8daae603
at
org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.removeBindingInternal(SimpleAddressManager.java:228)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.lambda$removeBinding$2(WildcardAddressManager.java:129)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressPartNode.visitValues(AddressPartNode.java:271)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressPartNode.visitNonWildcard(AddressPartNode.java:219)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressMap.visitMatching(AddressMap.java:64)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.removeBinding(WildcardAddressManager.java:129)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:988)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.removeBinding(ClusterConnectionImpl.java:1384)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.clearBindings(ClusterConnectionImpl.java:1249)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.close(ClusterConnectionImpl.java:1052)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.removeRecord(ClusterConnectionImpl.java:1619)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.fail(ClusterConnectionBridge.java:436)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.connectionFailed(BridgeImpl.java:699)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.callSessionFailureListeners(ClientSessionFactoryImpl.java:878)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:804)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:576)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1417)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:98)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:209)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1182)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
~[artemis-commons-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
~[artemis-commons-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.35.0.jar:2.35.0]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[?:?]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadF
[jira] [Commented] (ARTEMIS-5042) The load balancing is not working correctly when several brokers are down
[
https://issues.apache.org/jira/browse/ARTEMIS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883311#comment-17883311
]
Justin Bertram commented on ARTEMIS-5042:
-
The problem is being caused by this exception which is being thrown and
short-circuiting the removal of the cluster bridge flow record (resulting in
messages still being routed to the bridge's store-and-forward queue):
{noformat}
2024-09-20 10:34:50,998 WARN [org.apache.activemq.artemis.core.server]
AMQ68: Failed to remove a record
java.lang.IllegalStateException: Cannot find binding
mtmccon_ucpmula_sms_193#mcla_simusmsc3_ucpmula_queue9eb3fb16-71d6-11ef-9298-506b8daae603
at
org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.removeBindingInternal(SimpleAddressManager.java:228)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.lambda$removeBinding$2(WildcardAddressManager.java:129)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressPartNode.visitValues(AddressPartNode.java:271)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressPartNode.visitNonWildcard(AddressPartNode.java:219)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.AddressMap.visitMatching(AddressMap.java:64)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.removeBinding(WildcardAddressManager.java:129)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:988)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.removeBinding(ClusterConnectionImpl.java:1384)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.clearBindings(ClusterConnectionImpl.java:1249)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.close(ClusterConnectionImpl.java:1052)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.removeRecord(ClusterConnectionImpl.java:1619)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.fail(ClusterConnectionBridge.java:436)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.connectionFailed(BridgeImpl.java:699)
~[artemis-server-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.callSessionFailureListeners(ClientSessionFactoryImpl.java:878)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:804)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:576)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1417)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:98)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:209)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1182)
~[artemis-core-client-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
~[artemis-commons-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
~[artemis-commons-2.35.0.jar:2.35.0]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.35.0.jar:2.35.0]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[?:?]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.35.0.jar:2.35.0]{nofor
[jira] [Commented] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883140#comment-17883140 ] Justin Bertram commented on ARTEMIS-5027: - [~dragan.j.flipside], I don't have a precise date. > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png, JConsole.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5053) OOME during scaledown
[ https://issues.apache.org/jira/browse/ARTEMIS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883107#comment-17883107 ] Justin Bertram commented on ARTEMIS-5053: - The transactional behavior for scale-down should probably be configurable like it is for importing (i.e. on/off toggle & commit interval). > OOME during scaledown > - > > Key: ARTEMIS-5053 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5053 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Clustering >Affects Versions: 2.37.0 >Reporter: Emmanuel Hugonnet >Priority: Major > > When checking how scaledown behaves in WildFly we got an OOME when scaling > down the node in messaging cluster. It seems to be trying to send all > messages in [a single > transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. > More details [here|https://issues.redhat.com/browse/WFLY-19752]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5055) AIO not detected in official Ubuntu Docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Component/s: (was: ActiveMQ-Artemis-Native)
> AIO not detected in official Ubuntu Docker image
>
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Image
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ubuntu changed their libaio package name as was addressed
> [here|https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221].
>
> But the native {{LibaioContext}} link is still referencing {{libaio.so.1}},
> as seen in startup logs with debug enabled:
> {noformat}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.{noformat}
> NOTE: This only affects the Ubuntu image. Alpine is fine.
> The workaround is to either use the official Alpine image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {noformat}
> RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5055) AIO not detected in official Ubuntu Docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Description:
Ubuntu changed their libaio package name as was addressed
[here|https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221].
But the native {{LibaioContext}} link is still referencing {{libaio.so.1}}, as
seen in startup logs with debug enabled:
{noformat}
2024-09-18 15:40:43,807 DEBUG
[org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64 ->
not possible to load native library
java.lang.UnsatisfiedLinkError:
/opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
libaio.so.1: cannot open shared object file: No such file or directory{quote}
I think the link created
[here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
is stale, and a simple rebuild of artemis-native may be all that's needed?
Maybe the [dockerfile needs updating
there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
too though.{noformat}
NOTE: This only affects the Ubuntu image. Alpine is fine.
The workaround is to either use the official Alpine image instead, or create a
symlink to the old library name in a Dockerfile based on the official image:
{noformat}
RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
/lib/x86_64-linux-gnu/libaio.so.1{noformat}
was:
libaio changed their package name as was addressed here:
[https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
But the native LibaioContext link is still trying to reference libaio.so.1, as
seen in startup logs with debug enabled:
{quote}
2024-09-18 15:40:43,807 DEBUG
[org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64 ->
not possible to load native library
java.lang.UnsatisfiedLinkError:
/opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
libaio.so.1: cannot open shared object file: No such file or directory{quote}
I think the link created
[here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
is stale, and a simple rebuild of artemis-native may be all that's needed?
Maybe the [dockerfile needs updating
there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
too though.
NOTE: This only affects the ubuntu image; alpine is fine.
The workaround is to either use the alpine official image instead, or create a
symlink to the old library name in a Dockerfile based on the official image:
{quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
/lib/x86_64-linux-gnu/libaio.so.1
{quote}
> AIO not detected in official Ubuntu Docker image
>
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native, Image
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ubuntu changed their libaio package name as was addressed
> [here|https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221].
>
> But the native {{LibaioContext}} link is still referencing {{libaio.so.1}},
> as seen in startup logs with debug enabled:
> {noformat}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.{noformat}
> NOTE: This only affects the Ubuntu image. Alpine is fine.
> The workaround is to either use the official Alpine image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {noformat}
> RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1{noformat}
--
This message was sent by Atlas
[jira] [Updated] (ARTEMIS-5051) console jolokia default detector config makes unauthenticated mbean requests that are denied by ArtemisRbacMBeanServerBuilder
[
https://issues.apache.org/jira/browse/ARTEMIS-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5051:
Description:
The resulting errors are not consequential but very ugly.
{noformat}
broker with: java ... -Dhawtio.role=*
-Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder{noformat}
errors of the form:
{noformat}
AMQ601716: User anonymous@internal failed authentication on connection
management, reason: AMQ229031: Unable to validate user from management.
Username: null; SSL certificate subject DN: unavailable
jolokia-agent: Error while using detector GeronimoDetector:
java.lang.SecurityException: AMQ229031: Unable to validate user from
management. Username: null; SSL certificate subject DN: unavailable
java.lang.SecurityException: AMQ229031: Unable to validate user from
management. Username: null; SSL certificate subject DN: unavailable
at
org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.securityCheck(ArtemisRbacInvocationHandler.java:207)
at
org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.invoke(ArtemisRbacInvocationHandler.java:71)
at jdk.proxy2/jdk.proxy2.$Proxy29.queryNames
at
org.jolokia.backend.executor.AbstractMBeanServerExecutor.queryNames(AbstractMBeanServerExecutor.java:113)
at
org.jolokia.detector.AbstractServerDetector.searchMBeans(AbstractServerDetector.java:46)
at
org.jolokia.detector.AbstractServerDetector.getSingleStringAttribute(AbstractServerDetector.java:124)
at
org.jolokia.detector.GeronimoDetector.detect(GeronimoDetector.java:32){noformat}
was:
The resulting errors are not consequential but very ugly.
broker with: java ... -Dhawtio.role=*
-Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder
errors of the form:
AMQ601716: User anonymous@internal failed authentication on connection
management, reason: AMQ229031: Unable to validate user from management.
Username: null; SSL certificate subject DN: unavailable
jolokia-agent: Error while using detector GeronimoDetector:
java.lang.SecurityException: AMQ229031: Unable to validate user from
management. Username: null; SSL certificate subject DN: unavailable
java.lang.SecurityException: AMQ229031: Unable to validate user from
management. Username: null; SSL certificate subject DN: unavailable
at
org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.securityCheck(ArtemisRbacInvocationHandler.java:207)
at
org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.invoke(ArtemisRbacInvocationHandler.java:71)
at jdk.proxy2/jdk.proxy2.$Proxy29.queryNames
at
org.jolokia.backend.executor.AbstractMBeanServerExecutor.queryNames(AbstractMBeanServerExecutor.java:113)
at
org.jolokia.detector.AbstractServerDetector.searchMBeans(AbstractServerDetector.java:46)
at
org.jolokia.detector.AbstractServerDetector.getSingleStringAttribute(AbstractServerDetector.java:124)
at org.jolokia.detector.GeronimoDetector.detect(GeronimoDetector.java:32)
> console jolokia default detector config makes unauthenticated mbean requests
> that are denied by ArtemisRbacMBeanServerBuilder
> -
>
> Key: ARTEMIS-5051
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5051
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.37.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The resulting errors are not consequential but very ugly.
> {noformat}
> broker with: java ... -Dhawtio.role=*
> -Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder{noformat}
> errors of the form:
> {noformat}
> AMQ601716: User anonymous@internal failed authentication on connection
> management, reason: AMQ229031: Unable to validate user from management.
> Username: null; SSL certificate subject DN: unavailable
> jolokia-agent: Error while using detector GeronimoDetector:
> java.lang.SecurityException: AMQ229031: Unable to validate user from
> management. Username: null; SSL certificate subject DN: unavailable
> java.lang.SecurityException: AMQ229031: Unable to validate user from
> management. Username: null; SSL certificate subject DN: unavailable
> at
> org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.securityCheck(ArtemisRbacInvocationHandler.java:207)
> at
> org.apache.activemq.artemis.core.server.management.ArtemisRbacInvocationHandler.invoke(ArtemisRbacInvocationHandler.java:
[jira] [Updated] (ARTEMIS-5055) AIO not detected in official Ubuntu Docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Summary: AIO not detected in official Ubuntu Docker image (was: AIO not
detected in official ubuntu docker image)
> AIO not detected in official Ubuntu Docker image
>
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native, Image
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Justin Bertram
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5055) AIO not detected in official ubuntu docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Summary: AIO not detected in official ubuntu docker image (was: AIO not
available in official ubuntu docker image)
> AIO not detected in official ubuntu docker image
>
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native, Image
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Justin Bertram
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5039) Bump netty.version to 4.1.113.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5039: Issue Type: Dependency upgrade (was: Task) > Bump netty.version to 4.1.113.Final > --- > > Key: ARTEMIS-5039 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5039 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Broker >Affects Versions: 2.37.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Bump netty version to latest release. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-5055) AIO not available in official ubuntu docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-5055:
---
Assignee: Justin Bertram
> AIO not available in official ubuntu docker image
> -
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native, Image
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Justin Bertram
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5055) AIO not available in official ubuntu docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Component/s: ActiveMQ-Artemis-Native
> AIO not available in official ubuntu docker image
> -
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-5055) AIO not available in official ubuntu docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-5055:
---
Assignee: (was: Clebert Suconic)
> AIO not available in official ubuntu docker image
> -
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5055) AIO not available in official ubuntu docker image
[
https://issues.apache.org/jira/browse/ARTEMIS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5055:
Component/s: (was: ActiveMQ-Artemis-Native)
> AIO not available in official ubuntu docker image
> -
>
> Key: ARTEMIS-5055
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5055
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.36.0, 2.37.0
>Reporter: William Sperlazza
>Assignee: Clebert Suconic
>Priority: Minor
>
> libaio changed their package name as was addressed here:
> [https://github.com/apache/activemq-artemis/commit/86f36e95b09c709fb7e4af33f4a535f9a80d7221]
>
> But the native LibaioContext link is still trying to reference libaio.so.1,
> as seen in startup logs with debug enabled:
> {quote}
> 2024-09-18 15:40:43,807 DEBUG
> [org.apache.activemq.artemis.nativo.jlibaio.LibaioContext] artemis-native-64
> -> not possible to load native library
> java.lang.UnsatisfiedLinkError:
> /opt/activemq-artemis/bin/lib/linux-x86_64/libartemis-native-64.so:
> libaio.so.1: cannot open shared object file: No such file or directory{quote}
> I think the link created
> [here|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/c/CMakeLists.txt#L80C1-L80C22]
> is stale, and a simple rebuild of artemis-native may be all that's needed?
> Maybe the [dockerfile needs updating
> there|https://github.com/apache/activemq-artemis-native/blob/02ad87f08395993ae417ce75bf8ce78a3bc23e0a/src/main/docker/Dockerfile-ubuntu#L36]
> too though.
> NOTE: This only affects the ubuntu image; alpine is fine.
>
> The workaround is to either use the alpine official image instead, or create
> a symlink to the old library name in a Dockerfile based on the official image:
> {quote}RUN ln -s /lib/x86_64-linux-gnu/libaio.so.1t64
> /lib/x86_64-linux-gnu/libaio.so.1
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5053) OOME during scaledown
[ https://issues.apache.org/jira/browse/ARTEMIS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5053: Summary: OOME during scaledown (was: OOME during scaledown of node in Artemis/Messaging cluster) > OOME during scaledown > - > > Key: ARTEMIS-5053 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5053 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Clustering >Affects Versions: 2.37.0 >Reporter: Emmanuel Hugonnet >Priority: Major > > When checking how scaledown behaves in WildFly we got an OOME when scaling > down the node in messaging cluster. It seems to be trying to send all > messages in [a single > transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. > More details [here|https://issues.redhat.com/browse/WFLY-19752]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5054) large messages only forwarded to one subscriber when using STOMP on multicast address
[
https://issues.apache.org/jira/browse/ARTEMIS-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5054:
Description:
We noticed a bug that affects versions after 2.31.2. When sending a large
message using STOMP (in our use case, we used the stomp.py library from Python)
on a MULTICAST address with multiple non-durable queues, we noticed that only
one of the queues gets the message forwarded to it.
Note that the issue does not appear with messages that are not flagged as large
messages: all the queues get the message.
We conducted our test using 20MB messages using the Docker image
(docker.io/apache/activemq-artemis:2.37.0) without changing anything in the
configuration.
Sending a large message with STOMP on a MULTICAST queue generates the following
in Artemis logs:
{noformat}
2024-09-17 12:46:29,850 WARN [org.apache.activemq.artemis.core.protocol.stomp]
AMQ332069: Sent ERROR frame to STOMP client 10.0.2.100:34400: null
2024-09-17 12:46:29,851 WARN [org.apache.activemq.artemis.core.server]
AMQ222067: Connection failure has been detected: null [code=REMOTE_DISCONNECT]
2024-09-17 12:46:29,851 WARN [org.apache.activemq.artemis.core.server]
AMQ222061: Client connection failed, clearing up resources for session
dc1a3fc3-74f2-11ef-a9fa-caa03bc75f5c
2024-09-17 12:46:29,853 WARN [org.apache.activemq.artemis.core.server]
AMQ222107: Cleared up resources for session dc1a3fc3-74f2-11ef-a9fa-caa03bc75f5c
2024-09-17 12:46:29,850 WARN [org.apache.activemq.artemis.core.protocol.stomp]
AMQ332071: Unable to send message to client:
LargeServerMessage[messageID=34,durable=false,userID=null,priority=4,
timestamp=Tue Sep 17 12:46:29 UTC 2024,expiration=0, durable=false,
address=simulation.results.inflated-dimensions,
properties=TypedProperties[destination=simulation.results.inflated-dimensions,
content-length=7057754, _AMQ_LARGE_SIZE=7057754]]@132459861
java.lang.RuntimeException:
ActiveMQIllegalStateException[errorType=ILLEGAL_STATE message=File 34.tmp has a
null channel]
at
org.apache.activemq.artemis.core.persistence.impl.journal.LargeBody.getReadOnlyBodyBuffer(LargeBody.java:275)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.getReadOnlyBodyBuffer(LargeServerMessageImpl.java:257)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.protocol.stomp.VersionedStompFrameHandler.createMessageFrame(VersionedStompFrameHandler.java:334)
~[artemis-stomp-protocol-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.protocol.stomp.StompConnection.createStompMessage(StompConnection.java:630)
~[artemis-stomp-protocol-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.protocol.stomp.StompSession.sendMessage(StompSession.java:169)
~[artemis-stomp-protocol-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1215)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:528)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:4091)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:3325)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4459)
~[artemis-server-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
~[artemis-commons-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
~[artemis-commons-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.37.0.jar:2.37.0]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) [?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) [?:?]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.37.0.jar:2.37.0]
Caused by: org.apache.activemq.artemis.api.core.ActiveMQIllegalStateException:
File 34.tmp has a null channel
at
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.read(NIOSequentialFile.java:282)
~[artemis-journal-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.read(NIOSequentialFile.java:243)
~[artemis-journal-2.37.0.jar:2.37.0]
at
org.apache.activemq.artemis.core.persistence.impl.journal.LargeBody.getReadOnlyBodyBuffer(LargeBody.java:272)
~[artemis-server-2.37.0.jar:2.37.0]
... 15 more {noformat}
If you need me to create a
[jira] [Updated] (ARTEMIS-5053) OOME during scaledown of node in Artemis/Messaging cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5053: Description: When checking how scaledown behaves in WildFly we got an OOME when scaling down the node in messaging cluster. It seems to be trying to send all messages in [a single transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. More details [here|https://issues.redhat.com/browse/WFLY-19752]. was: When trying to check how scale down behave in WildFly we got an OOME when scaling down the node in messaging cluster. It seems to be trying to send all messages in [a single transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. More details [here|https://issues.redhat.com/browse/WFLY-19752]. > OOME during scaledown of node in Artemis/Messaging cluster > -- > > Key: ARTEMIS-5053 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5053 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Clustering >Affects Versions: 2.37.0 >Reporter: Emmanuel Hugonnet >Priority: Major > > When checking how scaledown behaves in WildFly we got an OOME when scaling > down the node in messaging cluster. It seems to be trying to send all > messages in [a single > transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. > More details [here|https://issues.redhat.com/browse/WFLY-19752]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5053) OOME during scaledown of node in Artemis/Messaging cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5053: Description: When trying to check how scale down behave in WildFly we got an OOME when scaling down the node in messaging cluster. It seems to be trying to send all messages in [a single transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. More details [here|https://issues.redhat.com/browse/WFLY-19752]. was: With WildFLy,trying to check how scale down would behave we got an OOME when scaling down the node in messaging cluster. It seems to be trying to send all messages in a single transaction: https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319 For more details to reproduce: https://issues.redhat.com/browse/WFLY-19752 > OOME during scaledown of node in Artemis/Messaging cluster > -- > > Key: ARTEMIS-5053 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5053 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Clustering >Affects Versions: 2.37.0 >Reporter: Emmanuel Hugonnet >Priority: Major > > When trying to check how scale down behave in WildFly we got an OOME when > scaling down the node in messaging cluster. It seems to be trying to send all > messages in [a single > transaction|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java#L262-L319]. > More details [here|https://issues.redhat.com/browse/WFLY-19752]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5050) misc improvements to 'Broker-to-Broker Connectivity' docs/index
[ https://issues.apache.org/jira/browse/ARTEMIS-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5050. - Resolution: Fixed > misc improvements to 'Broker-to-Broker Connectivity' docs/index > --- > > Key: ARTEMIS-5050 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5050 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Documentation >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Update the 'Broker-to-Broker Connectivity' section of the documentation > index. Expose the key AMQP Broker Connections functionality around Mirroring > and Federation in the index to make them more visible. Move the Core-based > Federation links beside the AMQP-based ones to have them nearer each other > and make clearer both exist. > Add Federation to the list of functionality types supported on the broker > connection. > Add some detail about the various examples for the AMQP based Federation. > Fix (/remove) a reference to the broker distribution for an example around > mirroring, as the examples are now independent. > Remove a note that broker-connections could support other protocols to > simplify things; there has been no movement that it will, such notes can be > added if it ever does occur. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5052) Hash authentication cache keys
Justin Bertram created ARTEMIS-5052: --- Summary: Hash authentication cache keys Key: ARTEMIS-5052 URL: https://issues.apache.org/jira/browse/ARTEMIS-5052 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5048) Use java.util.Base64
[
https://issues.apache.org/jira/browse/ARTEMIS-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-5048.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> Use java.util.Base64
>
>
> Key: ARTEMIS-5048
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5048
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We've traditionally used {{org.apache.activemq.artemis.utils.Base64}} for
> Base64 encoding/decoding. This implementation is based on public domain code
> from http://iharder.net/base64.
> In Java 8 {{java.util.Base64}} was introduced. I assumed we hadn't switched
> to this implementation for performance reasons so I created a simple
> JMH-based test to compare the two implementations and it appears to me that
> {{java.util.Base64}} is significantly faster than our current implementation.
> Using the JDK's class will simplify our code _and_ improve performance. Also,
> it should be 100% backwards compatible since Base64 encoding/decoding is
> standardized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5049) Add detailed logging for auth caches
Justin Bertram created ARTEMIS-5049: --- Summary: Add detailed logging for auth caches Key: ARTEMIS-5049 URL: https://issues.apache.org/jira/browse/ARTEMIS-5049 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5048) Use java.util.Base64
[
https://issues.apache.org/jira/browse/ARTEMIS-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5048:
Description:
We've traditionally used {{org.apache.activemq.artemis.utils.Base64}} for
Base64 encoding/decoding. This implementation is based on public domain code
from http://iharder.net/base64.
In Java 8 {{java.util.Base64}} was introduced. I assumed we hadn't switched to
this implementation for performance reasons so I created a simple JMH-based
test to compare the two implementations and it appears to me that
{{java.util.Base64}} is significantly faster than our current implementation.
Using the JDK's class will simplify our code _and_ improve performance. Also,
it should be 100% backwards compatible since Base64 encoding/decoding is
standardized.
was:
We've traditionally used {{org.apache.activemq.artemis.utils.Base64}} for
Base64 encoding/decoding. This implementation is based on public domain code
from http://iharder.net/base64.
In Java 5 {{java.util.Base64}} was introduced. I assumed we hadn't switched to
this implementation for performance reasons so I created a simple JMH-based
test to compare the two implementations and it appears to me that
{{java.util.Base64}} is significantly faster than our current implementation.
Using the JDK's class will simplify our code _and_ improve performance. Also,
it should be 100% backwards compatible since Base64 encoding/decoding is
standardized.
> Use java.util.Base64
>
>
> Key: ARTEMIS-5048
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5048
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> We've traditionally used {{org.apache.activemq.artemis.utils.Base64}} for
> Base64 encoding/decoding. This implementation is based on public domain code
> from http://iharder.net/base64.
> In Java 8 {{java.util.Base64}} was introduced. I assumed we hadn't switched
> to this implementation for performance reasons so I created a simple
> JMH-based test to compare the two implementations and it appears to me that
> {{java.util.Base64}} is significantly faster than our current implementation.
> Using the JDK's class will simplify our code _and_ improve performance. Also,
> it should be 100% backwards compatible since Base64 encoding/decoding is
> standardized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5048) Use java.util.Base64
Justin Bertram created ARTEMIS-5048:
---
Summary: Use java.util.Base64
Key: ARTEMIS-5048
URL: https://issues.apache.org/jira/browse/ARTEMIS-5048
Project: ActiveMQ Artemis
Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram
We've traditionally used {{org.apache.activemq.artemis.utils.Base64}} for
Base64 encoding/decoding. This implementation is based on public domain code
from http://iharder.net/base64.
In Java 5 {{java.util.Base64}} was introduced. I assumed we hadn't switched to
this implementation for performance reasons so I created a simple JMH-based
test to compare the two implementations and it appears to me that
{{java.util.Base64}} is significantly faster than our current implementation.
Using the JDK's class will simplify our code _and_ improve performance. Also,
it should be 100% backwards compatible since Base64 encoding/decoding is
standardized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5047) Lost the lock according to the monitor, notifying listeners
[
https://issues.apache.org/jira/browse/ARTEMIS-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5047:
Description:
After upgrading from version 2.23.1 to 2.33.0 the system has started to fail
due to a lock loss. This issue was not present in the previous version and has
only surfaced after the upgrade.
I have seen a similar issue.
{noformat}
(AuditLogger_impl.java:2843) - AMQ601767: STOMP connection c3e5b678 for user
unknown@10.118.189.108:64628 created FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug 2024 01:03:51,813 WARN
[Thread-0 (ActiveMQ-scheduled-threads)] (FileLockNodeManager.java:557) - Lost
the lock according to the monitor, notifying listeners FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug 2024 01:03:51,813 ERROR
[Thread-0 (ActiveMQ-scheduled-threads)] (ActiveMQServerLogger_impl.java:805) -
AMQ222010: Critical IO Error, shutting down the server. file=Lost NodeManager
lock, message=NULL FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|java.io.IOException: lost
lock{noformat}
was:
After upgrading from version 2.23.1 to 2.33.0, the system has started to fail
due to a lock loss. This issue was not present in the previous version and has
only surfaced after the upgrade.
I have seen a similar issue.
{code:java}
(AuditLogger_impl.java:2843) - AMQ601767: STOMP connection c3e5b678 for user
unknown@10.118.189.108:64628 created FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug 2024 01:03:51,813 WARN
[Thread-0 (ActiveMQ-scheduled-threads)] (FileLockNodeManager.java:557) - Lost
the lock according to the monitor, notifying listeners FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug 2024 01:03:51,813 ERROR
[Thread-0 (ActiveMQ-scheduled-threads)] (ActiveMQServerLogger_impl.java:805) -
AMQ222010: Critical IO Error, shutting down the server. file=Lost NodeManager
lock, message=NULL FINEST|6324/0|Service
com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|java.io.IOException: lost lock
{code}
> Lost the lock according to the monitor, notifying listeners
> ---
>
> Key: ARTEMIS-5047
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5047
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.33.0, 2.37.0
> Environment: * *Storage Type:* SMB share hosted on AWS FSxN
> * *Current Version:* NetApp Release 9.14.1P5
> * *Affected Version:* 2.33.0 / 2.37.0
> * *Previous Version:* 2.23.1 (issue not observed)
>Reporter: Juan
>Priority: Major
>
> After upgrading from version 2.23.1 to 2.33.0 the system has started to fail
> due to a lock loss. This issue was not present in the previous version and
> has only surfaced after the upgrade.
> I have seen a similar issue.
> {noformat}
> (AuditLogger_impl.java:2843) - AMQ601767: STOMP connection c3e5b678 for user
> unknown@10.118.189.108:64628 created FINEST|6324/0|Service
> com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug 2024 01:03:51,813
> WARN [Thread-0 (ActiveMQ-scheduled-threads)] (FileLockNodeManager.java:557) -
> Lost the lock according to the monitor, notifying listeners
> FINEST|6324/0|Service com.docshifter.mq.DocShifterMQ|24-08-22 01:03:51|22 Aug
> 2024 01:03:51,813 ERROR [Thread-0 (ActiveMQ-scheduled-threads)]
> (ActiveMQServerLogger_impl.java:805) - AMQ222010: Critical IO Error, shutting
> down the server. file=Lost NodeManager lock, message=NULL
> FINEST|6324/0|Service com.docshifter.mq.DocShifterMQ|24-08-22
> 01:03:51|java.io.IOException: lost lock{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4643) Web console authentication with Keycloak 31 doesn't work
[ https://issues.apache.org/jira/browse/ARTEMIS-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881586#comment-17881586 ] Justin Bertram commented on ARTEMIS-4643: - [~deamicis], PR for integration into ActiveMQ Artemis is here - https://github.com/apache/activemq-artemis/pull/5149. The new console is available at https://github.com/apache/activemq-artemis-console. You can build it and use it now although it probably needs a bit of polishing. The more folks who use it and provide feedback the better it will be. > Web console authentication with Keycloak 31 doesn't work > > > Key: ARTEMIS-4643 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4643 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.32.0 >Reporter: Nicolas De Amicis >Priority: Major > > Authentication with Keycloak for the ActiveMQ Artemis web console doesn't > work with recent Keycloak versions. Tested with Keycloak 22 and 23.0.6 > (latest). > I have tested Hawtio 2.17.7 (i.e. the version of the web console component of > ActiveMQ Artemis) and it doesn't work. I have also tested Hawtio 3.0.1 > (latest version available) and it works with Keycloak 31. > I think Hawtio needs to be upgraded to 3.0.1 in ActiveMQ Artemis. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-4781) AMQP message leaking large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881396#comment-17881396
]
Justin Bertram edited comment on ARTEMIS-4781 at 9/12/24 6:59 PM:
--
[~erwindon], thanks for the test! It made diagnosing the issue much simpler.
I've sent a PR to resolve it.
was (Author: jbertram):
[~erwindon], thanks for the test! It make diagnosing the issue much simpler.
I've sent a PR to resolve it.
> AMQP message leaking large message file
> ---
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4781) AMQP message leaking large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881396#comment-17881396
]
Justin Bertram commented on ARTEMIS-4781:
-
[~erwindon], thanks for the test! It make diagnosing the issue much simpler.
I've sent a PR to resolve it.
> AMQP message leaking large message file
> ---
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4781) AMQP message leaking large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4781:
---
Assignee: Justin Bertram
> AMQP message leaking large message file
> ---
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4781) AMQP message leaking large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4781:
Summary: AMQP message leaking large message file (was: on-disk files for
large messages are not always removed)
> AMQP message leaking large message file
> ---
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5045) Don't change the Micrometer MeterRegistry config
[ https://issues.apache.org/jira/browse/ARTEMIS-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5045: Description: For embedded use-cases the Micrometer MeterRegistry may be passed in from the application and used for other meters unrelated to the broker. Therefore, the broker should not change the config of the MeterRegistry (e.g. by adding common tags to all meters) as the config change(s) may be incompatible with the needs of the embedding application. > Don't change the Micrometer MeterRegistry config > > > Key: ARTEMIS-5045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > For embedded use-cases the Micrometer MeterRegistry may be passed in from the > application and used for other meters unrelated to the broker. Therefore, the > broker should not change the config of the MeterRegistry (e.g. by adding > common tags to all meters) as the config change(s) may be incompatible with > the needs of the embedding application. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5045) Don't change the Micrometer MeterRegistry config
Justin Bertram created ARTEMIS-5045: --- Summary: Don't change the Micrometer MeterRegistry config Key: ARTEMIS-5045 URL: https://issues.apache.org/jira/browse/ARTEMIS-5045 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5044) Bump io.micrometer:micrometer-core from 1.13.3 to 1.13.4
Justin Bertram created ARTEMIS-5044: --- Summary: Bump io.micrometer:micrometer-core from 1.13.3 to 1.13.4 Key: ARTEMIS-5044 URL: https://issues.apache.org/jira/browse/ARTEMIS-5044 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-5036) Performance regression with Micrometer
[
https://issues.apache.org/jira/browse/ARTEMIS-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879732#comment-17879732
]
Justin Bertram edited comment on ARTEMIS-5036 at 9/10/24 4:12 PM:
--
As a potential work-around, if you don't need metrics for temporary queues then
you can disable them. Details are in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#temporary-queues].
was (Author: jbertram):
As a potential work-around, if you don't need metrics for temporary queues then
you disable them. Details are in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#temporary-queues].
> Performance regression with Micrometer
> ---
>
> Key: ARTEMIS-5036
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5036
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.36.0
>Reporter: Josh Byster
>Priority: Major
>
> With the bump to Micrometer v1.13.2, I pinpointed a clear performance
> regression where the broker completely spiraled on temp queue deletion:
> https://github.com/micrometer-metrics/micrometer/issues/5466
> Moreover, this looping happens in a synchronized block in PostOffice, which
> completely stops other critical tasks.
> {code:java}
> java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
> io.micrometer.core.instrument.Tags.equals(Tags.java:177)
> java.base/java.util.Objects.equals(Objects.java:77)
> io.micrometer.core.instrument.Meter$Id.equals(Meter.java:359)
> io.micrometer.core.instrument.util.MeterEquivalence.equals(MeterEquivalence.java:39)
> io.micrometer.core.instrument.AbstractMeter.equals(AbstractMeter.java:43)
> io.micrometer.core.instrument.MeterRegistry.remove(MeterRegistry.java:762)
> io.micrometer.core.instrument.MeterRegistry.remove(MeterRegistry.java:723)
> org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:183)
> org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.unregisterMeters(ManagementServiceImpl.java:353)
> org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.unregisterAddress(ManagementServiceImpl.java:293)
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeAddressInfo(PostOfficeImpl.java:896)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3981)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3955)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2514)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2452)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:1160)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1174)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.callFailureListeners(OpenWireConnection.java:509)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:735)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:480)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processRemoveConnection(OpenWireConnection.java:1825)
> org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:366)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5025) Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.1.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5025: Summary: Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.1.Final (was: Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.0.Final) > Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to > 2.2.1.Final > -- > > Key: ARTEMIS-5025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5025 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5042) The load balancing is not working correctly when several brokers are down
[ https://issues.apache.org/jira/browse/ARTEMIS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880682#comment-17880682 ] Justin Bertram commented on ARTEMIS-5042: - bq. The node or nodes that remain alive will not detect if another node comes back up again. That is incorrect. If the node that stopped is restarted *before* the other nodes have given up trying to reconnect then the other nodes will reconnect and the messages in the store-and-forward queues will be distributed to the restarted node as if nothing happened. If the node that stopped is restarted *after* the other nodes have given up trying to reconnect then the store-and-forward queues on the other nodes will have been cleaned up and all the messages in them will have been put into their corresponding local queues. However, the restarted node will send a "node announce" message to the other nodes in the cluster and they will all establish new cluster-connections to the restarted node (and create the requisite internal store-and-forward queues, etc.). bq. The node which has back up alive, will always remain as down for the rest of the nodes that are still up. That is incorrect. See the previous answer for details. bq. This gonna work like this until the nodes that were up, get restarted. That is incorrect. See the previous answer for details. > The load balancing is not working correctly when several brokers are down > - > > Key: ARTEMIS-5042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5042 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Balancer >Affects Versions: 2.35.0 > Environment: Cluster Configuration broker.xml: > > > > 6 > 5000 > 500 > 1.0 > 5000 > -1 > -1 > false > artemis > ON_DEMAND > 1 > > node0 > node1 > node2 > > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Major > Attachments: 1NodoUp.PNG, 3Nodosup.PNG, > QueueInternWithMessageNoConsumer.PNG > > > The load balancing is not working correctly when several brokers are down. > With the configuration we have in the cluster, we understand that this should > not be happening. The load balancing should be smart and not send messages to > the nodes that are down." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5042) The load balancing is not working correctly when several brokers are down
[ https://issues.apache.org/jira/browse/ARTEMIS-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5042. - Assignee: Justin Bertram Resolution: Not A Bug > The load balancing is not working correctly when several brokers are down > - > > Key: ARTEMIS-5042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5042 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Balancer >Affects Versions: 2.35.0 > Environment: Cluster Configuration broker.xml: > > > > 6 > 5000 > 500 > 1.0 > 5000 > -1 > -1 > false > artemis > ON_DEMAND > 1 > > node0 > node1 > node2 > > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Major > Attachments: 1NodoUp.PNG, 3Nodosup.PNG, > QueueInternWithMessageNoConsumer.PNG > > > The load balancing is not working correctly when several brokers are down. > With the configuration we have in the cluster, we understand that this should > not be happening. The load balancing should be smart and not send messages to > the nodes that are down." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-2784) Could not decode properties for CoreMessage ... java.lang.IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/ARTEMIS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-2784.
---
> Could not decode properties for CoreMessage ...
> java.lang.IndexOutOfBoundsException
> ---
>
> Key: ARTEMIS-2784
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2784
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.12.0
>Reporter: Noah Zucker
>Priority: Major
>
> Our application is observing a large number of messages from Artemis
> experiencing the following error
> Server Version: ArtemisMQ 2.12.0
> Client Version: org.hornetq hornetq-core 2.2.7.Final
> {code}
> Could not decode properties for
> CoreMessage[messageID=0,durable=true,userID=null,priority=4, ti
> mestamp=1590674773446,expiration=0,address=null, propertiesLocation=145:
> java.lang.IndexOutOfBoundsException
> activemq-artemis 2020-05-28 14:09:41,364 WARN
> [org.apache.activemq.artemis.core.message.impl.CoreMessage] Failed message
> has messageID=0 and the following buffer:
> activemq-artemis +-+
> activemq-artemis | 0 1 2 3 4 5 6 7 8 9 a b c d e f |
> activemq-artemis
> ++-++
> activemq-artemis || 00 00 00 7d 00 00 00 66 00 66 7b 20 22 74 22 20
> |...}...f.f{ "t" |
> activemq-artemis |0010| 3a 20 22 63 6f 6d 2e 6e 6f 76 75 73 2e 61 6e 61
> |: "com.novus.ana|
> activemq-artemis |0020| 6c 79 74 69 63 73 2e 75 74 69 6c 2e 74 61 73 6b
> |lytics.util.task|
> activemq-artemis |0030| 73 2e 41 73 79 6e 63 43 6f 6e 73 75 6d 65 72 4d
> |s.AsyncConsumerM|
> activemq-artemis |0040| 65 73 73 61 67 65 22 20 2c 20 22 6d 73 67 22 20
> |essage" , "msg" |
> activemq-artemis |0050| 3a 20 22 66 65 61 74 75 72 65 46 6c 61 67 43 61
> |: "featureFlagCa|
> activemq-artemis |0060| 63 68 65 2e 69 6e 76 61 6c 69 64 61 74 65 22 7d
> |che.invalidate"}|
> activemq-artemis |0070| 00 00 00 f2 00 00 00 00 00 00 00 00 00 00 03 ff
> ||
> activemq-artemis |0080| 00 00 00 00 00 00 00 00 00 00 01 72 5b 9a d5 c6
> |...r[...|
> activemq-artemis |0090| 04 01 00 00 00 01 00 00 00 16 5f 00 48 00 51 00
> |.._.H.Q.|
> activemq-artemis |00a0| 5f 00 44 00 55 00 50 00 4c 00 5f 00 49 00 44 00
> |_.D.U.P.L._.I.D.|
> activemq-artemis |00b0| 0a 00 00 00 30 35 00 65 00 63 00 66 00 63 00 35
> |05.e.c.f.c.5|
> activemq-artemis |00c0| 00 35 00 35 00 64 00 39 00 31 00 33 00 62 00 32
> |.5.5.d.9.1.3.b.2|
> activemq-artemis |00d0| 00 34 00 65 00 66 00 30 00 32 00 32 00
> |.4.e.f.0.2.2. |
> activemq-artemis
> ++-++
> {code}
> Our client-side is also having trouble reading incoming text messages in its
> onMessage callback. We encounter this with frequency: {{Unable to parse
> string bodybuffer from Msg 'class
> org.hornetq.core.client.impl.ClientMessageImpl' having id=4530593 !!!
> Details: java.lang.IndexOutOfBoundsException: Not enough readable bytes -
> Need 24, maximum is 20}}
> Apologies for being open ended on this, please let me know what additional
> details to provide.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5040) Improve Failure mode when handling a burst of incoming connections
[ https://issues.apache.org/jira/browse/ARTEMIS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880346#comment-17880346 ] Justin Bertram commented on ARTEMIS-5040: - Also, do you need persistent subscriptions? If not, I'm curious how the broker functions for you with [persistent subscriptions disabled|https://activemq.apache.org/components/artemis/documentation/latest/mqtt.html#persistent-subscriptions]. > Improve Failure mode when handling a burst of incoming connections > -- > > Key: ARTEMIS-5040 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5040 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.37.0 > Environment: 2.37.00 running in Docker >Reporter: Tom Tichy >Priority: Major > > I have a few thousand of badly behaving IoT clients that connect at the same > time. > Artemis starts throwing "AMQ85: Unable to store MQTT state within given > timeout: 5000ms", which is understandable. > What is not ideal is that even after the burst of incoming connection stops, > the broker gets into a state where it is effectively not functional for the > next 10-15 minutes. It just continues to throw exceptions and is unable to > function. > I have done some testing with other brokers. They fail as well, but after the > connection burst stops, they recover immediately and continue to function. > That would be the desired behavior for Artemis as well. > (Apache Jmeter jmx file available) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5040) Improve Failure mode when handling a burst of incoming connections
[
https://issues.apache.org/jira/browse/ARTEMIS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880345#comment-17880345
]
Justin Bertram commented on ARTEMIS-5040:
-
Is it throwing the same {{AMQ85}} code or something else during the "next
10-15 minutes"?
> Improve Failure mode when handling a burst of incoming connections
> --
>
> Key: ARTEMIS-5040
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5040
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.37.0
> Environment: 2.37.00 running in Docker
>Reporter: Tom Tichy
>Priority: Major
>
> I have a few thousand of badly behaving IoT clients that connect at the same
> time.
> Artemis starts throwing "AMQ85: Unable to store MQTT state within given
> timeout: 5000ms", which is understandable.
> What is not ideal is that even after the burst of incoming connection stops,
> the broker gets into a state where it is effectively not functional for the
> next 10-15 minutes. It just continues to throw exceptions and is unable to
> function.
> I have done some testing with other brokers. They fail as well, but after the
> connection burst stops, they recover immediately and continue to function.
> That would be the desired behavior for Artemis as well.
> (Apache Jmeter jmx file available)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880343#comment-17880343 ] Justin Bertram commented on ARTEMIS-5027: - [~dragan.j.flipside], I expect 2.38.0 to be released in the next few weeks. > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png, JConsole.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.
[jira] [Assigned] (ARTEMIS-5037) AMQ Broker Mirroring: One to Many - avoid the infinite loop of the messages
[ https://issues.apache.org/jira/browse/ARTEMIS-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-5037: --- Assignee: Thomas Lavocat > AMQ Broker Mirroring: One to Many - avoid the infinite loop of the messages > --- > > Key: ARTEMIS-5037 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5037 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Thomas Lavocat >Assignee: Thomas Lavocat >Priority: Major > > AMQ Broker Mirroring: One to Many - avoid the infinite loop of the messages: > if we have a->b-c->a.. > a message will circulate forever in the mirrors -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5036) Performance regression with Micrometer
[
https://issues.apache.org/jira/browse/ARTEMIS-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879732#comment-17879732
]
Justin Bertram commented on ARTEMIS-5036:
-
As a potential work-around, if you don't need metrics for temporary queues then
you disable them. Details are in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#temporary-queues].
> Performance regression with Micrometer
> ---
>
> Key: ARTEMIS-5036
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5036
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.36.0
>Reporter: Josh Byster
>Priority: Major
>
> With the bump to Micrometer v1.13.2, I pinpointed a clear performance
> regression where the broker completely spiraled on temp queue deletion:
> https://github.com/micrometer-metrics/micrometer/issues/5466
> Moreover, this looping happens in a synchronized block in PostOffice, which
> completely stops other critical tasks.
> {code:java}
> java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
> io.micrometer.core.instrument.Tags.equals(Tags.java:177)
> java.base/java.util.Objects.equals(Objects.java:77)
> io.micrometer.core.instrument.Meter$Id.equals(Meter.java:359)
> io.micrometer.core.instrument.util.MeterEquivalence.equals(MeterEquivalence.java:39)
> io.micrometer.core.instrument.AbstractMeter.equals(AbstractMeter.java:43)
> io.micrometer.core.instrument.MeterRegistry.remove(MeterRegistry.java:762)
> io.micrometer.core.instrument.MeterRegistry.remove(MeterRegistry.java:723)
> org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:183)
> org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.unregisterMeters(ManagementServiceImpl.java:353)
> org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.unregisterAddress(ManagementServiceImpl.java:293)
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeAddressInfo(PostOfficeImpl.java:896)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3981)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3955)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2514)
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2452)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:1160)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1174)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.callFailureListeners(OpenWireConnection.java:509)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:735)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:480)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processRemoveConnection(OpenWireConnection.java:1825)
> org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:366)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4805) Null dereferencing in ScaleDownHandler.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4805.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> Null dereferencing in ScaleDownHandler.java
> ---
>
> Key: ARTEMIS-4805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4805
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
>
> In [line
> 333|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} variable {{queueCreateSession}} is
> initialized
> {code:java}
> ClientSession queueCreateSession = sessionFactory.createSession(user,
> password, false, true, true, false, 0);{code}
> In [line
> 851|https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java]
> in {{ClientSessionFactoryImp.java}}, the code synchronizes with the
> {{sessions}} collection and checks whether the current session is closed or
> whether the client protocol manager is down. If the closed session or
> inactive client protocol manager condition is met, the session is closed and
> {{null}} is returned
> {code:java}
> if (closed || !clientProtocolManager.isAlive()) {
> session.close();
> return null;
> }{code}
> The {{queueCreateSession}} variable could potentially be {{null}}.
> In [line
> 357|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} variable {{queueCreateSession}} is passed
> to the function {{createQueueWithRoutingTypeIfNecessaryAndGetID}} as the
> first argument:
> {code:java}
> queueID = createQueueWithRoutingTypeIfNecessaryAndGetID(queueCreateSession,
> queue, message.getAddressSimpleString(), message.getRoutingType());{code}
> In [line
> 450|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} potential {{null}} dereference occurs:
> {code:java}
> session.createQueue(new QueueConfiguration(...));{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5028) Use a default filter when none is specified for management ops
[
https://issues.apache.org/jira/browse/ARTEMIS-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-5028.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> Use a default filter when none is specified for management ops
> --
>
> Key: ARTEMIS-5028
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5028
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a small usability improvement for management whereby invocations of
> some operations no longer require JSON boilerplate. It impacts the following
> operations on the {{ActiveMQServerControl}}:
> * {{listConnections}}
> * {{listSessions}}
> * {{listAddresses}}
> * {{listQueues}}
> * {{listConsumers}}
> * {{listProducers}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5033) Avoid NPE on method processAddSession in OpenWireConnection
Justin Bertram created ARTEMIS-5033:
---
Summary: Avoid NPE on method processAddSession in
OpenWireConnection
Key: ARTEMIS-5033
URL: https://issues.apache.org/jira/browse/ARTEMIS-5033
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Justin Bertram
Avoid a {{NullPointerException}} that can occur on OpenWire reconnections.
Seen stack trace :
{noformat}
Errors occurred during the buffering operation :
java.lang.NullPointerException
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddSession(OpenWireConnection.java:1491)
at org.apache.activemq.command.SessionInfo.visit(SessionInfo.java:66)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:366)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:309)
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:723)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1475)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1338)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1387)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4182) fill client-id for cluster connections
[ https://issues.apache.org/jira/browse/ARTEMIS-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879563#comment-17879563 ] Justin Bertram commented on ARTEMIS-4182: - [~erwindon], technically speaking it would be possible to make the implementation pluggable and even have a few implementations we ship to configure it different ways, but that's not what my PR is about. Ultimately I think plugins here are too complex for something this simple. If further configuration is desired then I think we'd just add a new configuration element that folks can set however they like. > fill client-id for cluster connections > -- > > Key: ARTEMIS-4182 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4182 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Broker >Affects Versions: 2.28.0 >Reporter: Erwin Dondorp >Priority: Major > Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > when running Artemis in a cluster, the brokers have connections between them. > these are easily identifiable in the list of connections because the "Users" > field is filled in with the username that was specified in setting > `cluster-user`. > but it is unclear where each connection goes to. > !image-2023-02-25-13-27-08-542.png! > > additional information: > the field "Client ID" is filled in with the remote hostname when using > broker-connection/amqp-connection. > wish: > (also) fill in field ClientID of the cluster connections. > e.g. with the broker-name or from a new parameter `cluster-clientid` -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5029) Bump jetty.version from 10.0.23 to 10.0.24
[ https://issues.apache.org/jira/browse/ARTEMIS-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5029. - Fix Version/s: 2.38.0 Resolution: Fixed > Bump jetty.version from 10.0.23 to 10.0.24 > -- > > Key: ARTEMIS-5029 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5029 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5029) Bump jetty.version from 10.0.23 to 10.0.24
Justin Bertram created ARTEMIS-5029: --- Summary: Bump jetty.version from 10.0.23 to 10.0.24 Key: ARTEMIS-5029 URL: https://issues.apache.org/jira/browse/ARTEMIS-5029 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5028) Use a default filter when none is specified for management ops
[
https://issues.apache.org/jira/browse/ARTEMIS-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5028:
Priority: Minor (was: Major)
> Use a default filter when none is specified for management ops
> --
>
> Key: ARTEMIS-5028
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5028
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Minor
>
> This is a small usability improvement for management whereby invocations of
> some operations no longer require JSON boilerplate. It impacts the following
> operations on the {{ActiveMQServerControl}}:
> * {{listConnections}}
> * {{listSessions}}
> * {{listAddresses}}
> * {{listQueues}}
> * {{listConsumers}}
> * {{listProducers}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5028) Use a default filter when none is specified for management ops
[ https://issues.apache.org/jira/browse/ARTEMIS-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5028: Description: This is a small usability improvement for management whereby invocations of some operations no longer require JSON boilerplate. > Use a default filter when none is specified for management ops > -- > > Key: ARTEMIS-5028 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5028 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > This is a small usability improvement for management whereby invocations of > some operations no longer require JSON boilerplate. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5027. - Resolution: Duplicate > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png, JConsole.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4962) possible NPE in FilterImpl
[
https://issues.apache.org/jira/browse/ARTEMIS-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4962.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> possible NPE in FilterImpl
> --
>
> Key: ARTEMIS-4962
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4962
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In {{FilterImpl}} there is potential {{NullPointerException}} in the private
> method {{GetHeaderFieldValue()}} ([line
> 169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]).
> When condition in line 161 is {{true}} and condition in line 164 is {{false}}
> then {{null}} return value of {{msg.getUserID()}} (cause in line 161 was true
> condition) derefers in 169. Is it absolutely true that in complex these
> conditions must only works as "true+true" or be skipped by first "false"?
> Does this part of code need another check before 169 line?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4933) org.apache.activemq.artemis.boot.Artemis.execute(File, File, String[]) creates a java.net.URLClassLoader classloader, which should be performed within a doPrivileged
[
https://issues.apache.org/jira/browse/ARTEMIS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878984#comment-17878984
]
Justin Bertram commented on ARTEMIS-4933:
-
I'm not entirely sure this is necessary given the fact that the Security
Manager is being removed from Java completely.
> org.apache.activemq.artemis.boot.Artemis.execute(File, File, String[])
> creates a java.net.URLClassLoader classloader, which should be performed
> within a doPrivileged block
> ---
>
> Key: ARTEMIS-4933
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4933
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Suhov Roman
>Priority: Major
>
> file:
> [https://github.com/apache/activemq-artemis/blob/main/artemis-boot/src/main/java/org/apache/activemq/artemis/boot/Artemis.java]
> line: 146
> Instantiating a {{URLClassLoader}} in the {{execute}} method without using a
> {{doPrivileged}} block can cause problems, especially in security-restricted
> environments such as the Java Security Manager.
> You need to wrap the {{URLClassLoader}} creation in a {{doPrivileged}} block
> something like this:
> {code:java}
> ClassLoader originalCL = Thread.currentThread().getContextClassLoader();
> try {
> URLClassLoader loader =
> AccessController.doPrivileged((PrivilegedAction) () ->
> new URLClassLoader(urls.toArray(new URL[urls.size()])));
> Thread.currentThread().setContextClassLoader(loader);
> Class clazz =
> loader.loadClass("org.apache.activemq.artemis.cli.Artemis");
> Method method = clazz.getMethod("execute", Boolean.TYPE, File.class,
> File.class, args.getClass());
> try {
> return method.invoke(null, true, fileHome, fileInstance, args);
> } catch (InvocationTargetException e) {
> throw e.getTargetException();
> }
> } finally {
> Thread.currentThread().setContextClassLoader(originalCL);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4933) org.apache.activemq.artemis.boot.Artemis.execute(File, File, String[]) creates a java.net.URLClassLoader classloader, which should be performed within a doPrivileged bl
[
https://issues.apache.org/jira/browse/ARTEMIS-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4933:
Description:
file:
[https://github.com/apache/activemq-artemis/blob/main/artemis-boot/src/main/java/org/apache/activemq/artemis/boot/Artemis.java]
line: 146
Instantiating a {{URLClassLoader}} in the {{execute}} method without using a
{{doPrivileged}} block can cause problems, especially in security-restricted
environments such as the Java Security Manager.
You need to wrap the {{URLClassLoader}} creation in a {{doPrivileged}} block
something like this:
{code:java}
ClassLoader originalCL = Thread.currentThread().getContextClassLoader();
try {
URLClassLoader loader =
AccessController.doPrivileged((PrivilegedAction) () ->
new URLClassLoader(urls.toArray(new URL[urls.size()])));
Thread.currentThread().setContextClassLoader(loader);
Class clazz = loader.loadClass("org.apache.activemq.artemis.cli.Artemis");
Method method = clazz.getMethod("execute", Boolean.TYPE, File.class,
File.class, args.getClass());
try {
return method.invoke(null, true, fileHome, fileInstance, args);
} catch (InvocationTargetException e) {
throw e.getTargetException();
}
} finally {
Thread.currentThread().setContextClassLoader(originalCL);
}{code}
was:
file:
[https://github.com/apache/activemq-artemis/blob/main/artemis-boot/src/main/java/org/apache/activemq/artemis/boot/Artemis.java]
line: 146
Instantiating a _URLClassLoader_ in the execute method without using a
_doPrivileged_ block can cause problems, especially in security-restricted
environments such as the Java Security Manager.
You need to wrap the URLClassLoader creation in a doPrivileged block something
like this:
_ClassLoader originalCL = Thread.currentThread().getContextClassLoader();_
_try {_
_URLClassLoader loader =
AccessController.doPrivileged((PrivilegedAction) () ->_
_new URLClassLoader(urls.toArray(new URL[urls.size()])));_
_Thread.currentThread().setContextClassLoader(loader);_
_Class clazz =
loader.loadClass("org.apache.activemq.artemis.cli.Artemis");_
_Method method = clazz.getMethod("execute", Boolean.TYPE, File.class,
File.class, args.getClass());_
_try {_
_return method.invoke(null, true, fileHome, fileInstance, args);_
_} catch (InvocationTargetException e) {_
_throw e.getTargetException();_
_}_
_} finally {_
_Thread.currentThread().setContextClassLoader(originalCL);_
_}_
> org.apache.activemq.artemis.boot.Artemis.execute(File, File, String[])
> creates a java.net.URLClassLoader classloader, which should be performed
> within a doPrivileged block
> ---
>
> Key: ARTEMIS-4933
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4933
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Suhov Roman
>Priority: Major
>
> file:
> [https://github.com/apache/activemq-artemis/blob/main/artemis-boot/src/main/java/org/apache/activemq/artemis/boot/Artemis.java]
> line: 146
> Instantiating a {{URLClassLoader}} in the {{execute}} method without using a
> {{doPrivileged}} block can cause problems, especially in security-restricted
> environments such as the Java Security Manager.
> You need to wrap the {{URLClassLoader}} creation in a {{doPrivileged}} block
> something like this:
> {code:java}
> ClassLoader originalCL = Thread.currentThread().getContextClassLoader();
> try {
> URLClassLoader loader =
> AccessController.doPrivileged((PrivilegedAction) () ->
> new URLClassLoader(urls.toArray(new URL[urls.size()])));
> Thread.currentThread().setContextClassLoader(loader);
> Class clazz =
> loader.loadClass("org.apache.activemq.artemis.cli.Artemis");
> Method method = clazz.getMethod("execute", Boolean.TYPE, File.class,
> File.class, args.getClass());
> try {
> return method.invoke(null, true, fileHome, fileInstance, args);
> } catch (InvocationTargetException e) {
> throw e.getTargetException();
> }
> } finally {
> Thread.currentThread().setContextClassLoader(originalCL);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4339) Configure dead letter addresses through API
[
https://issues.apache.org/jira/browse/ARTEMIS-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878926#comment-17878926
]
Justin Bertram commented on ARTEMIS-4339:
-
You should be able to do what you want with the management API. Specifically
the {{addAddressSettings}} method which takes a JSON formatted {{String}}, e.g.:
{code:java}
ActiveMQServerControl serverControl = ...
String returnedSettings = serverControl.addAddressSettings("myAddress", new
AddressSettings().setDeadLetterAddress(SimpleString.of("myDeadLetterAddress")).toJSON());{code}
This is _much_ simpler than the example code you provided.
If you call {{addAddressSettings}} multiple times then any settings you add or
change for that match will be updated. If you want to remove certain address
settings then use the {{removeAddressSettings}} method.
Adding, updating, or removing address settings is not available from the
ActiveMQ Artemis CLI. You should use the management API directly for that
functionality instead.
> Configure dead letter addresses through API
> ---
>
> Key: ARTEMIS-4339
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4339
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: API
> Environment: Artemis client is
> org.apache.activemq:artemis-core-client:2.19.1, Java code is using the
> Artemis Core API.
> Artemis server appears to be 2.28.0, and is running in a Docker container.
>Reporter: Chelsea Salyards
>Priority: Major
>
> My project is working on an integration with ActiveMQ Artemis, and it has the
> requirement to create queues and dead letter queues on the fly. When the
> queues are created, we want to be able to dynamically set the queue to use
> dead letter queues we just created and not just use the default dead letter
> address for the server. I would like to be able to do this through the Java
> API and the Artemis CLI.
> [This
> page|https://activemq.apache.org/components/artemis/documentation/latest/undelivered-messages.html]
> documents how to set through the broker.xml, which will not work for our use
> case. I have seen references on the internet that suggest at one point the
> API allowed users to set dead letter addresses through the JMX API, but none
> of that seems to exist anymore.
> The closest I have been able to accomplish this is through the following code:
> {code:java}
> String queueName = ... // whatever the name of the custom queue is
> String deadLetterChannelName = // whatever the name of the custom
> dead letter address is
> ActiveMQServerControl serverControl = ... // insert method to
> pull ActiveMQServerControl object from JMX
> String jsonAddressSettings =
> serverControl.getAddressSettingsAsJSON(queueName);
> AddressSettingsInfo defaultInfo =
> AddressSettingsInfo.from(jsonAddressSettings);
>
> serverControl.addAddressSettings(
> queueName,
> deadLetterChannelName,
> deadLetterChannelName,
> defaultInfo.getExpiryDelay(),
> false,
> defaultInfo.getMaxDeliveryAttempts(),
> defaultInfo.getMaxSizeBytes(),
> defaultInfo.getPageSizeBytes(),
> defaultInfo.getPageCacheMaxSize(),
> defaultInfo.getRedeliveryDelay(),
> defaultInfo.getRedeliveryMultiplier(),
> defaultInfo.getMaxRedeliveryDelay(),
> defaultInfo.getRedistributionDelay(),
> true,
> defaultInfo.getAddressFullMessagePolicy(),
> defaultInfo.getSlowConsumerThreshold(),
> defaultInfo.getSlowConsumerCheckPeriod(),
> defaultInfo.getSlowConsumerPolicy(),
> false,
> false,
> false,
> false
> {code}
> Looking at the Artemis console this appears to be setting my custom dead
> letter address from the default, but I haven't figured out what happens if
> addAddressSettings() gets called multiple times or if there is a way to
> remove address settings later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4339) Configure dead letter addresses through API
[
https://issues.apache.org/jira/browse/ARTEMIS-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4339.
-
Resolution: Information Provided
> Configure dead letter addresses through API
> ---
>
> Key: ARTEMIS-4339
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4339
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: API
> Environment: Artemis client is
> org.apache.activemq:artemis-core-client:2.19.1, Java code is using the
> Artemis Core API.
> Artemis server appears to be 2.28.0, and is running in a Docker container.
>Reporter: Chelsea Salyards
>Priority: Major
>
> My project is working on an integration with ActiveMQ Artemis, and it has the
> requirement to create queues and dead letter queues on the fly. When the
> queues are created, we want to be able to dynamically set the queue to use
> dead letter queues we just created and not just use the default dead letter
> address for the server. I would like to be able to do this through the Java
> API and the Artemis CLI.
> [This
> page|https://activemq.apache.org/components/artemis/documentation/latest/undelivered-messages.html]
> documents how to set through the broker.xml, which will not work for our use
> case. I have seen references on the internet that suggest at one point the
> API allowed users to set dead letter addresses through the JMX API, but none
> of that seems to exist anymore.
> The closest I have been able to accomplish this is through the following code:
> {code:java}
> String queueName = ... // whatever the name of the custom queue is
> String deadLetterChannelName = // whatever the name of the custom
> dead letter address is
> ActiveMQServerControl serverControl = ... // insert method to
> pull ActiveMQServerControl object from JMX
> String jsonAddressSettings =
> serverControl.getAddressSettingsAsJSON(queueName);
> AddressSettingsInfo defaultInfo =
> AddressSettingsInfo.from(jsonAddressSettings);
>
> serverControl.addAddressSettings(
> queueName,
> deadLetterChannelName,
> deadLetterChannelName,
> defaultInfo.getExpiryDelay(),
> false,
> defaultInfo.getMaxDeliveryAttempts(),
> defaultInfo.getMaxSizeBytes(),
> defaultInfo.getPageSizeBytes(),
> defaultInfo.getPageCacheMaxSize(),
> defaultInfo.getRedeliveryDelay(),
> defaultInfo.getRedeliveryMultiplier(),
> defaultInfo.getMaxRedeliveryDelay(),
> defaultInfo.getRedistributionDelay(),
> true,
> defaultInfo.getAddressFullMessagePolicy(),
> defaultInfo.getSlowConsumerThreshold(),
> defaultInfo.getSlowConsumerCheckPeriod(),
> defaultInfo.getSlowConsumerPolicy(),
> false,
> false,
> false,
> false
> {code}
> Looking at the Artemis console this appears to be setting my custom dead
> letter address from the default, but I haven't figured out what happens if
> addAddressSettings() gets called multiple times or if there is a way to
> remove address settings later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4962) possible NPE in FilterImpl
[ https://issues.apache.org/jira/browse/ARTEMIS-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4962: Summary: possible NPE in FilterImpl (was: possible NRE in FilterImpl) > possible NPE in FilterImpl > -- > > Key: ARTEMIS-4962 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4962 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Ekaterina Zilotina >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > In FilterImpl class there is potential *NullReferenceException* in private > method *GetHeaderFieldValue()* ([line > 169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]). > When condition in line 161 is true and condition in line 164 is false null > return value of *msg.getUserID()* (cause in line 161 was true condition) > derefers in 169. Is it absolutely true that in complex these conditions must > only works as "true+true" or be skipped by first "false"? Does this part of > code need another check before 169 line? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4962) possible NPE in FilterImpl
[
https://issues.apache.org/jira/browse/ARTEMIS-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4962:
Description:
In {{FilterImpl}} there is potential {{NullPointerException}} in the private
method {{GetHeaderFieldValue()}} ([line
169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]).
When condition in line 161 is {{true}} and condition in line 164 is {{false}}
then {{null}} return value of {{msg.getUserID()}} (cause in line 161 was true
condition) derefers in 169. Is it absolutely true that in complex these
conditions must only works as "true+true" or be skipped by first "false"? Does
this part of code need another check before 169 line?
was:
In FilterImpl class there is potential *NullReferenceException* in private
method *GetHeaderFieldValue()* ([line
169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]).
When condition in line 161 is true and condition in line 164 is false null
return value of *msg.getUserID()* (cause in line 161 was true condition)
derefers in 169. Is it absolutely true that in complex these conditions must
only works as "true+true" or be skipped by first "false"? Does this part of
code need another check before 169 line?
> possible NPE in FilterImpl
> --
>
> Key: ARTEMIS-4962
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4962
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In {{FilterImpl}} there is potential {{NullPointerException}} in the private
> method {{GetHeaderFieldValue()}} ([line
> 169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]).
> When condition in line 161 is {{true}} and condition in line 164 is {{false}}
> then {{null}} return value of {{msg.getUserID()}} (cause in line 161 was true
> condition) derefers in 169. Is it absolutely true that in complex these
> conditions must only works as "true+true" or be skipped by first "false"?
> Does this part of code need another check before 169 line?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878886#comment-17878886 ] Justin Bertram commented on ARTEMIS-5027: - This looks very similar to ARTEMIS-5017 which was fixed last week. Would you be willing to test the [latest snapshot build|https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-artemis/2.38.0-SNAPSHOT/] of ActiveMQ Artemis to see if the fix for ARTEMIS-5017 solves your issue? > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- This message was sent by Atlassian Jira (v8.20.10#820010) ---
[jira] [Resolved] (ARTEMIS-4381) resource-limit-settings max-connections should be called max-sessions
[
https://issues.apache.org/jira/browse/ARTEMIS-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4381.
-
Resolution: Duplicate
> resource-limit-settings max-connections should be called max-sessions
> -
>
> Key: ARTEMIS-4381
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4381
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Geert Schuring
>Priority: Major
>
> The configuration setting "max-connections" should be called "max-sessions"
> since it limits the amounts of sessions and not the connections.
>
> [https://activemq.apache.org/components/artemis/documentation/latest/resource-limits.html#configuring-limits-via-resource-limit-settings]
> After having limited the 'connections' using this setting I get the following
> error even though this user has only 1 connection to the broker: (it does try
> to create more then 1 sessions)
> {quote}{{AMQ229110: Too many sessions for user 'user'}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5023) Web temp directory cleaner is moot now
[
https://issues.apache.org/jira/browse/ARTEMIS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5023:
Description:
Before the changes from ARTEMIS-4525 temporary web resources could proliferate
and consume inordinate amounts of disk space because their directory names were
generated uniquely every time Jetty was started. However, now that they are
deterministic no proliferation is possible. Jetty will create the directories
when it starts, remove them when it stops, and if it fails to clean-up on
shutdown (e.g. crash from OOME) it will clean-up and recreate when it starts.
Therefore, our own house-keeping of those directories is no longer needed and,
in fact, causes problems. For example, when executing the
{{restartEmbeddedWebServer}} management operation the temp web resources will
actually be removed inadvertently causing the web console to fail. Exceptions
like this are thrown when HTTP requests are made to the console:
{noformat}
WARN [org.eclipse.jetty.server.HttpChannelState] unhandled due to prior
sendError
org.eclipse.jetty.io.EofException: Closed
at
org.eclipse.jetty.server.HttpOutput.checkWritable(HttpOutput.java:747)
~[jetty-server-10.0.22.jar:10.0.22]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:777)
~[jetty-server-10.0.22.jar:10.0.22]
at java.base/java.io.OutputStream.write(OutputStream.java:124) ~[?:?]
at
io.hawt.web.filters.BaseTagHrefFilter.doFilter(BaseTagHrefFilter.java:81) ~[?:?]
at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:616)
~[jetty-security-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1553)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1306)
~[jetty-server-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129)
~[jetty-server-10.0.22.jar:10.0.22]
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:215)
~[jetty-server-10.0.22.jar:10.0.22]
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:135)
~[jetty-server-10.0.22.jar:10.0.22]
at io.hawt.web.auth.Redirector.doForward(Redirector.java:45) ~[?:?]
at io.hawt.web.auth.LoginServlet.doGet(LoginServlet.java:59) ~[?:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
~[jetty-servlet-api-4.0.6.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
~[jetty-servlet-api-4.0.6.jar:?]2
at
org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1419)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1665)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
io.hawt.web.auth.LoginRedirectFilter.doFilter(LoginRedirectFilter.java:63)
~[?:?]
at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.22.jar:10.0.22]
at
io.h
[jira] [Resolved] (ARTEMIS-5025) Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.0.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5025. - Fix Version/s: 2.38.0 Resolution: Fixed > Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to > 2.2.0.Final > -- > > Key: ARTEMIS-5025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5025 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5024) Bump org.apache.commons:commons-lang3 from 3.16.0 to 3.17.0
[ https://issues.apache.org/jira/browse/ARTEMIS-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5024. - Fix Version/s: 2.38.0 Resolution: Fixed > Bump org.apache.commons:commons-lang3 from 3.16.0 to 3.17.0 > --- > > Key: ARTEMIS-5024 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5024 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5025) Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.0.Final
Justin Bertram created ARTEMIS-5025: --- Summary: Bump org.jboss.marshalling:jboss-marshalling-river from 2.1.4.Final to 2.2.0.Final Key: ARTEMIS-5025 URL: https://issues.apache.org/jira/browse/ARTEMIS-5025 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5024) Bump org.apache.commons:commons-lang3 from 3.16.0 to 3.17.0
Justin Bertram created ARTEMIS-5024: --- Summary: Bump org.apache.commons:commons-lang3 from 3.16.0 to 3.17.0 Key: ARTEMIS-5024 URL: https://issues.apache.org/jira/browse/ARTEMIS-5024 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4804) Null dereferencing in ScaleDownHandler.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4804:
---
Assignee: Justin Bertram
> Null dereferencing in ScaleDownHandler.java
> ---
>
> Key: ARTEMIS-4804
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4804
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
>
> In [line
> 332|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} variable {{session}} is initialized
> {code:java}
> ClientSession session = sessionFactory.createSession(user, password, true,
> false, false, false, 0);{code}
> In [line
> 851|https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java]
> in {{{}ClientSessionFactoryImp.java{}}}, the code synchronizes with the
> sessions collection and checks whether the current session is closed or
> whether the client protocol manager is down. If the closed session or
> inactive client protocol manager condition is met, the session is closed and
> null is returned
> {code:java}
> if (closed || !clientProtocolManager.isAlive()){
> session.close();
> return null;
> }{code}
> The {{session}} variable could potentially be {{{}null{}}}.
> In [line
> 339|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} potential null dereference occurs.
> {code:java}
> session.start(xid, XAResource.TMNOFLAGS);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4805) Null dereferencing in ScaleDownHandler.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4805:
---
Assignee: Justin Bertram
> Null dereferencing in ScaleDownHandler.java
> ---
>
> Key: ARTEMIS-4805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4805
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
>
> In [line
> 333|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} variable {{queueCreateSession}} is
> initialized
> {code:java}
> ClientSession queueCreateSession = sessionFactory.createSession(user,
> password, false, true, true, false, 0);{code}
> In [line
> 851|https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java]
> in {{ClientSessionFactoryImp.java}}, the code synchronizes with the
> {{sessions}} collection and checks whether the current session is closed or
> whether the client protocol manager is down. If the closed session or
> inactive client protocol manager condition is met, the session is closed and
> {{null}} is returned
> {code:java}
> if (closed || !clientProtocolManager.isAlive()) {
> session.close();
> return null;
> }{code}
> The {{queueCreateSession}} variable could potentially be {{null}}.
> In [line
> 357|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} variable {{queueCreateSession}} is passed
> to the function {{createQueueWithRoutingTypeIfNecessaryAndGetID}} as the
> first argument:
> {code:java}
> queueID = createQueueWithRoutingTypeIfNecessaryAndGetID(queueCreateSession,
> queue, message.getAddressSimpleString(), message.getRoutingType());{code}
> In [line
> 450|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScaleDownHandler.java]
> in file {{ScaleDownHandler.java}} potential {{null}} dereference occurs:
> {code:java}
> session.createQueue(new QueueConfiguration(...));{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5013) Don't override Netty leak detection config on client
[ https://issues.apache.org/jira/browse/ARTEMIS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5013. - Fix Version/s: 2.38.0 Resolution: Fixed > Don't override Netty leak detection config on client > > > Key: ARTEMIS-5013 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5013 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4485) console shows broker-attributes instead of the requested address-attributes
[
https://issues.apache.org/jira/browse/ARTEMIS-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878235#comment-17878235
]
Justin Bertram commented on ARTEMIS-4485:
-
For what it's worth, this will likely be moot once the [new
console|https://github.com/apache/activemq-artemis-console] is integrated.
> console shows broker-attributes instead of the requested address-attributes
> ---
>
> Key: ARTEMIS-4485
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4485
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.31.2
>Reporter: Erwin Dondorp
>Priority: Minor
>
> When using the "attributes"-button at the end of a table-row in the Addresses
> page/table, sometimes the broker-attributes are shown instead of the expected
> address-attributes.
> Unfortunately, this is not 100% reproducible, but I've seen it several times
> now and not doubting my actions.
> this time I was able to capture the brower console log:
> {noformat}
> [artemis-plugin] current
> nid=root-org.apache.activemq.artemis-XYZ-addresses-FULL/ADDRESS/NAME/HERE
> app-efb360a568.js:1:9987
> [artemis-plugin]
> targetNID=root-org.apache.activemq.artemis-XYZ-addresses-FULL/ADDRESS/NAME/HERE
> app-efb360a568.js:1:9987
> [hawtio-core-tasks] Executing tasks: LocationChangeStartTasks
> app-efb360a568.js:1:9987
> [hawtio-core-tasks] Executing task: ConParam with parameters:
> Array(3) [ {…},
> "http://artemis-apps-0:58161/console/artemis/attributes?tab=artemis&nid=root-org.apache.activemq.artemis-XYZ-addresses-FULL%2FADDRESS%2FNAME%2FHERE";,
>
> "http://artemis-apps-0:58161/console/artemis/artemisAddresses?tab=artemis&nid=root-org.apache.activemq.artemis-XYZ-addresses-FULL%2FADDRESS%2FNAME%2FHERE";
> ]
> app-efb360a568.js:1:9987
> [hawtio-core-tasks] Executing task: RefreshUserSession with parameters:
> Array(3) [ {…},
> "http://artemis-apps-0:58161/console/artemis/attributes?tab=artemis&nid=root-org.apache.activemq.artemis-XYZ-addresses-FULL%2FADDRESS%2FNAME%2FHERE";,
>
> "http://artemis-apps-0:58161/console/artemis/artemisAddresses?tab=artemis&nid=root-org.apache.activemq.artemis-XYZ-addresses-FULL%2FADDRESS%2FNAME%2FHERE";
> ]
> app-efb360a568.js:1:9987
> [hawtio-core-template-cache] request for template at:
> plugins/jmx/html/attributes/attributes.html app-efb360a568.js:1:9987
> [hawtio-core-template-cache] Getting template:
> plugins/jmx/html/attributes/attributes.html app-efb360a568.js:1:9987
> [hawtio-core-template-cache] Found template for URL:
> plugins/jmx/html/attributes/attributes.html app-efb360a568.js:1:9987
> [hawtio-core-template-cache] Adding template: attributeModal.html
> app-efb360a568.js:1:9987
> [hawtio-jmx] attribute - nid:
> root-org.apache.activemq.artemis-XYZ-addresses-FULL/ADDRESS/NAME/HERE
> app-efb360a568.js:1:9987
> [hawtio-console-assembly] Updated session. Response:
> Object { data: "ok", status: 200, headers: Wn(t)
> , config: {…}, statusText: "OK", xhrStatus: "complete" }
> app-efb360a568.js:1:9987
> [hawtio-jmx] Updated attributes info cache for mbean
> org.apache.activemq.artemis:broker="XYZ-ABC-123"
> Object { op: {…}, attr: {…}, class:
> "org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl",
> desc: "Information on the management interface of the MBean" }
> attr: Object { AddressMemoryUsage: {…}, ManagementAddress: {…},
> ConnectorServices: {…}, … }
> class:
> "org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl"
> desc: "Information on the management interface of the MBean"
> op: Object { removeAddressSettings: {…}, listSessions: (2) […], scaleDown:
> {…}, … }
> : Object { … }
> {noformat}
> my observation is that the "targetNID" is incorrect.
> the brokername that appears in it is truncated on the first "-" character.
> in the redacted output, this is visible as "XYZ"(truncated) vs
> "XYZ-ABC-123"(correct).
> when I manually fix the redirect URL to include the full brokerName, then the
> requested information is shown, confirming this a bit more.
> after shallow investigation:
> I think it is likely a defect in (or misuse of) function {{getRootNid}} in
> file {{addresses.js}}.
> It seems that {{getRootNid}} assumes that the broker-name does not contain a
> {{-}} itself.
> Therefore it accidentally shortens the broker-name, leading to the above
> problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[
https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878229#comment-17878229
]
Justin Bertram commented on ARTEMIS-4519:
-
_Some_ sessions used for internal management start with {{management::}}, but
not all of them do. You can see 2 sessions being created for MQTT clients in
{{org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager#connect}}.
Neither of these are named with {{management::}}.
> Why can a client connect and see two different session IDs on the console?
> --
>
> Key: ARTEMIS-4519
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4519
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
>Affects Versions: 2.31.2
>Reporter: gongping.zhu
>Priority: Major
> Attachments: image-2023-11-30-11-00-08-171.png
>
>
> Why can a client connect and see two different session IDs on the console?
> After a successful client connection, it will call before Create Session
> twice, with the same connId but different sessions?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4519) Why can a client connect and see two different session IDs on the console?
[ https://issues.apache.org/jira/browse/ARTEMIS-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4519. - Assignee: Justin Bertram Resolution: Information Provided > Why can a client connect and see two different session IDs on the console? > -- > > Key: ARTEMIS-4519 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4519 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.31.2 >Reporter: gongping.zhu >Assignee: Justin Bertram >Priority: Major > Attachments: image-2023-11-30-11-00-08-171.png > > > Why can a client connect and see two different session IDs on the console? > After a successful client connection, it will call before Create Session > twice, with the same connId but different sessions? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4935) remove unused variable in ProcessBuilder.ProcessLogger
[ https://issues.apache.org/jira/browse/ARTEMIS-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4935: Summary: remove unused variable in ProcessBuilder.ProcessLogger (was: The `failed` field in the `ProcessLogger` class is not used) > remove unused variable in ProcessBuilder.ProcessLogger > -- > > Key: ARTEMIS-4935 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4935 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Suhov Roman >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > file: > [https://github.com/apache/activemq-artemis/blob/main/artemis-cli/src/main/java/org/apache/activemq/artemis/cli/process/ProcessBuilder.java] > line: 117 > The failed field in the ProcessLogger class is unused (that is, it is > declared but not read or written to elsewhere in the code). > The failed field is initialized to false, but is not used anywhere else. > There may have been attempts in code in the past to use this field, but the > current code does not, and it remains unused. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4935) remove unused variable in ProcessBuilder.ProcessLogger
[ https://issues.apache.org/jira/browse/ARTEMIS-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4935: --- Assignee: Justin Bertram > remove unused variable in ProcessBuilder.ProcessLogger > -- > > Key: ARTEMIS-4935 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4935 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Suhov Roman >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > file: > [https://github.com/apache/activemq-artemis/blob/main/artemis-cli/src/main/java/org/apache/activemq/artemis/cli/process/ProcessBuilder.java] > line: 117 > The failed field in the ProcessLogger class is unused (that is, it is > declared but not read or written to elsewhere in the code). > The failed field is initialized to false, but is not used anywhere else. > There may have been attempts in code in the past to use this field, but the > current code does not, and it remains unused. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4957) unused value in Redistributor class
[
https://issues.apache.org/jira/browse/ARTEMIS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4957:
---
Assignee: Justin Bertram
> unused value in Redistributor class
> ---
>
> Key: ARTEMIS-4957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4957
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.23.0
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/48cd586ac59440c99d1bde9477b82c4b8c44a16b]
> there is "{*}pendingRuns"{*} variable (ReusableLatch type) , which is not
> using in class.
> How about to remove it?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4958) unused variable in AddressImpl class
[
https://issues.apache.org/jira/browse/ARTEMIS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4958:
---
Assignee: Justin Bertram
> unused variable in AddressImpl class
>
>
> Key: ARTEMIS-4958
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4958
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/546bbfebfb7ce04b1d65039add13113d950fea88#diff-9a54e5b113b1e78b84644f0a7d408ff19904051dc956036badf90c6da8da28d6]
> there is "{*}linkedAddresses{*}" variable (List type) , which is
> not using in class.
> How about to remove it?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4972) The start() method should use a lock to access the expected binding variables.
[ https://issues.apache.org/jira/browse/ARTEMIS-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4972. - Resolution: Fixed > The start() method should use a lock to access the expected binding variables. > -- > > Key: ARTEMIS-4972 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4972 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Suhov Roman >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > File: > [https://github.com/apache/activemq-artemis/blob/2.36.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/group/impl/LocalGroupingHandler.java] > Line: 325 - 327 > > The start() method should use a lock to access the expectedBindings variable > to ensure thread safety, since other methods use the lock and interact with > expectedBindings at the same time. > Using the lock in the start() method ensures that access to the > expectedBindings variable is safe in a multi-threaded environment, preventing > potential thread contention issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4934) It is necessary to handle a possible error when deleting a file in the WebTmpCleaner method.java:93
[
https://issues.apache.org/jira/browse/ARTEMIS-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4934.
-
Assignee: Justin Bertram
Resolution: Invalid
This is moot now thanks to ARTEMIS-5023 which will remove this class entirely.
> It is necessary to handle a possible error when deleting a file in the
> WebTmpCleaner method.java:93
> ---
>
> Key: ARTEMIS-4934
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4934
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Suhov Roman
>Assignee: Justin Bertram
>Priority: Major
>
> file:
> [https://github.com/apache/activemq-artemis/blob/main/artemis-web/src/main/java/org/apache/activemq/artemis/component/WebTmpCleaner.java]
> line: 95
> The deleteFolder method needs to handle cases where the file.delete() method
> might return false. This can happen when the file does not exist (The file or
> directory has already been deleted by another process or manually) or if the
> user does not have permission to delete (The current user or process does not
> have sufficient rights to delete the file or directory).
> To improve code reliability, it is recommended to handle potential errors
> when calling file.delete(). This can be done, for example, like this:
> _public static final void deleteFolder(final File file) {_
> _if (file.isDirectory()) {_
> _String[] files = file.list();_
> _if (files != null) {_
> _for (String path : files) {_
> _File f = new File(file, path);_
> _deleteFolder(f);_
> _}_
> _}_
> _}_
> _if (!file.delete()) {_
> _System.err.println("Failed to delete file or directory: " +
> file.getAbsolutePath());_
> _}_
> _}_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4962) possible NRE in FilterImpl
[ https://issues.apache.org/jira/browse/ARTEMIS-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4962: --- Assignee: Justin Bertram > possible NRE in FilterImpl > -- > > Key: ARTEMIS-4962 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4962 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Ekaterina Zilotina >Assignee: Justin Bertram >Priority: Major > > In FilterImpl class there is potential *NullReferenceException* in private > method *GetHeaderFieldValue()* ([line > 169|https://github.com/apache/activemq-artemis/blob/75f17ba64df10663a14fcc85bcb5398d23941b6d/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L169]). > When condition in line 161 is true and condition in line 164 is false null > return value of *msg.getUserID()* (cause in line 161 was true condition) > derefers in 169. Is it absolutely true that in complex these conditions must > only works as "true+true" or be skipped by first "false"? Does this part of > code need another check before 169 line? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5018) Eliminate deprecated use of Class.newInstance
[ https://issues.apache.org/jira/browse/ARTEMIS-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-5018. - Fix Version/s: 2.38.0 Resolution: Fixed > Eliminate deprecated use of Class.newInstance > - > > Key: ARTEMIS-5018 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5018 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5023) Web temp directory cleaner is moot now
[
https://issues.apache.org/jira/browse/ARTEMIS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-5023:
Description:
Before the changes from ARTEMIS-4525 temporary web resources could proliferate
and consume inordinate amounts of disk space because their directory names were
generated uniquely every time Jetty was started. However, now that they are
deterministic no proliferation is possible. Jetty will create the directories
when it starts, remove them when it stops, and if it fails to clean-up on
shutdown (e.g. crash from OOME) it will clean-up and recreate when it starts.
Therefore, our own house-keeping of those directories is no longer needed and,
in fact, causes problems. For example, when executing the
{{restartEmbeddedWebServer}} management operation the temp web resources will
actually be removed inadvertently causing the web console to fail.
> Web temp directory cleaner is moot now
> --
>
> Key: ARTEMIS-5023
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5023
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> Before the changes from ARTEMIS-4525 temporary web resources could
> proliferate and consume inordinate amounts of disk space because their
> directory names were generated uniquely every time Jetty was started.
> However, now that they are deterministic no proliferation is possible. Jetty
> will create the directories when it starts, remove them when it stops, and if
> it fails to clean-up on shutdown (e.g. crash from OOME) it will clean-up and
> recreate when it starts.
> Therefore, our own house-keeping of those directories is no longer needed
> and, in fact, causes problems. For example, when executing the
> {{restartEmbeddedWebServer}} management operation the temp web resources will
> actually be removed inadvertently causing the web console to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5023) Web temp directory cleaner is moot now
Justin Bertram created ARTEMIS-5023: --- Summary: Web temp directory cleaner is moot now Key: ARTEMIS-5023 URL: https://issues.apache.org/jira/browse/ARTEMIS-5023 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4965) Possible null dereference when property is missing in journal-sql.properties file
[ https://issues.apache.org/jira/browse/ARTEMIS-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4965: --- Assignee: Justin Bertram > Possible null dereference when property is missing in journal-sql.properties > file > - > > Key: ARTEMIS-4965 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4965 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Suhov Roman >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > File: > https://github.com/apache/activemq-artemis/blob/main/artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/sql/PropertySQLProvider.java > In lines 81,93,94,95,101,106,111,116 and further in the PropertySQLProvider > class, where properties are received from the journal-sql.properties file, a > null dereference is possible. > A dereference can occur if the required property is missing from the > journal-sql.properties file. A null check must be added to all method return > values. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4968) The getManagementConnector method returns the value of the mBeanServer field, which can be changed in the start and stop methods.
[
https://issues.apache.org/jira/browse/ARTEMIS-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4968.
-
Assignee: Justin Bertram
Resolution: Invalid
In my opinion this is a false positive. The {{start}} and {{stop}} methods use
{{synchronized}} blocks to ensure the consistency of {{isStarted}}. It's not
directly to protect access to {{mBeanServer}}.
> The getManagementConnector method returns the value of the mBeanServer field,
> which can be changed in the start and stop methods.
> -
>
> Key: ARTEMIS-4968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4968
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Suhov Roman
>Assignee: Justin Bertram
>Priority: Major
>
> File:
> [https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/ManagementContext.java]
> Line: 113 - 116
> The getManagementConnector method returns the value of the mBeanServer field,
> which can be changed in the start and stop methods. These methods are already
> synchronized to prevent race conditions when accessing the mBeanServer field.
> However, to ensure thread safety when reading this field, the
> getManagementConnector method must also be synchronized.
> public synchronized ManagementConnector getManagementConnector()
> {
> return mBeanServer;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4937) Resolve virtual thread pinning issues in client side Artemis code
[
https://issues.apache.org/jira/browse/ARTEMIS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877569#comment-17877569
]
Justin Bertram commented on ARTEMIS-4937:
-
It's not obvious that all pinning, no matter what, is problematic (as noted
[here|https://mikemybytes.com/2024/02/28/curiosities-of-java-virtual-threads-pinning-with-synchronized/]).
Therefore, occurrences of pinning should be evaluated on a case by case basis.
> Resolve virtual thread pinning issues in client side Artemis code
> -
>
> Key: ARTEMIS-4937
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4937
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>
> When I was testing executing WildFly workloads on a virtual thread, turning
> on JVM thread pinning logging (see WFLY-19536) revealed pinning happening in
> client-side Artemis code (e.g. sending JMS messages). This issue is to trace
> working with the Artemis community to resolve these issues and get the fixed
> code into WildFly.
> An example:
> {noformat}
> 2024-07-18 04:55:23,274 INFO [stdout] (ForkJoinPool-1-worker-1)
> Thread[#297,ForkJoinPool-1-worker-1,5,CarrierThreads]
> 2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:185)
> 2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.System$2.parkVirtualThread(System.java:2648)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:67)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:267)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:756)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1126)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:276)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.waitForTopology(ClientSessionFactoryImpl.java:544)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:773)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:913)
> <== monitors:1{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4937) Resolve virtual thread pinning issues in client side Artemis code
[
https://issues.apache.org/jira/browse/ARTEMIS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4937:
Description:
When I was testing executing WildFly workloads on a virtual thread, turning on
JVM thread pinning logging (see WFLY-19536) revealed pinning happening in
client-side Artemis code (e.g. sending JMS messages). This issue is to trace
working with the Artemis community to resolve these issues and get the fixed
code into WildFly.
An example:
{noformat}
2024-07-18 04:55:23,274 INFO [stdout] (ForkJoinPool-1-worker-1)
Thread[#297,ForkJoinPool-1-worker-1,5,CarrierThreads]
2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:185)
2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.System$2.parkVirtualThread(System.java:2648)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:67)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:267)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:756)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1126)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:276)
2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.waitForTopology(ClientSessionFactoryImpl.java:544)
2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:773)
2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
org.apache.activemq.artemis.client@2.35.0//org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:913)
<== monitors:1{noformat}
was:
When I was testing executing WildFly workloads on a virtual thread, turning on
JVM thread pinning logging (see WFLY-19536) revealed pinning happening in
client-side Artemis code (e.g. sending JMS messages). This issue is to trace
working with the Artemis community to resolve these issues and get the fixed
code into WildFly.
See occurrences of 'onPinned' in
https://ci.wildfly.org/repository/download/WF_MainNightlyJobs_StandardLinuxJdk21/446569:id/testsuite/integration/basic/target/wildfly/standalone/log/server.log.
Lines in the stack trace annotated with "<== monitor" show where a monitor
lock was taken that results in pinning when blocking code executes.
An example:
2024-07-18 04:55:23,274 INFO [stdout] (ForkJoinPool-1-worker-1)
Thread[#297,ForkJoinPool-1-worker-1,5,CarrierThreads]
2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:185)
2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.lang.System$2.parkVirtualThread(System.java:2648)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:67)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:267)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:756)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1126)
2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
java.base/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:
[jira] [Resolved] (ARTEMIS-4688) add idle subscription removal after timeout
[ https://issues.apache.org/jira/browse/ARTEMIS-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4688. - Resolution: Information Provided > add idle subscription removal after timeout > --- > > Key: ARTEMIS-4688 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4688 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.32.0 >Reporter: Erwin Dondorp >Priority: Major > > In Artemis, messages expire by their individual message setting. With some > variations possible via address settings in the broker configuration. > But unused subscription-queues are never removed, except for the non-durable > ones. > Request is to add a idle-timeout for queues from durable subscriptions. The > subscription and its queue should then be deleted when there are no > subscribers during a given time-period. > I believe ActiveMQ Classic has this via the offlineDurableSubscriberTimeout > setting, see also > https://activemq.apache.org/components/classic/documentation/manage-durable-subscribers. > > This subject was also mentioned a while back in > [https://stackoverflow.com/questions/56115426/apache-activemq-artemis-durable-subscription-ttl;] > but, for our use-cases, using only message-expiry is not sufficient. this is > because each abandonned durable subscription still stores messages, and is > thus using resources. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-4688) add idle subscription removal after timeout
[
https://issues.apache.org/jira/browse/ARTEMIS-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877566#comment-17877566
]
Justin Bertram edited comment on ARTEMIS-4688 at 8/29/24 3:08 AM:
--
I think you can do this by setting something like this:
{code:xml}
true
6
-1{code}
This will auto-delete queues regardless of how many messages they contain once
no consumers have been connected for 1 minute.
Related [documentation is
here|https://activemq.apache.org/components/artemis/documentation/latest/address-settings.html].
was (Author: jbertram):
I think you can do this by setting something like this:
{code:xml}
true
6
-1{code}
This will auto-delete queues regardless of how many messages they contain once
no consumers have been connected for 1 minute.
> add idle subscription removal after timeout
> ---
>
> Key: ARTEMIS-4688
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4688
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.32.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> In Artemis, messages expire by their individual message setting. With some
> variations possible via address settings in the broker configuration.
> But unused subscription-queues are never removed, except for the non-durable
> ones.
> Request is to add a idle-timeout for queues from durable subscriptions. The
> subscription and its queue should then be deleted when there are no
> subscribers during a given time-period.
> I believe ActiveMQ Classic has this via the offlineDurableSubscriberTimeout
> setting, see also
> https://activemq.apache.org/components/classic/documentation/manage-durable-subscribers.
>
> This subject was also mentioned a while back in
> [https://stackoverflow.com/questions/56115426/apache-activemq-artemis-durable-subscription-ttl;]
> but, for our use-cases, using only message-expiry is not sufficient. this is
> because each abandonned durable subscription still stores messages, and is
> thus using resources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-4688) add idle subscription removal after timeout
[
https://issues.apache.org/jira/browse/ARTEMIS-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877566#comment-17877566
]
Justin Bertram edited comment on ARTEMIS-4688 at 8/29/24 3:07 AM:
--
I think you can do this by setting something like this:
{code:xml}
true
6
-1{code}
This will auto-delete queues regardless of how many messages they contain once
no consumers have been connected for 1 minute.
was (Author: jbertram):
I think you can do this by setting something like this:
{code:xml}
true
-1
6{code}
This will auto-delete queues regardless of how many messages they contain once
no consumers have been connected for 1 minute.
> add idle subscription removal after timeout
> ---
>
> Key: ARTEMIS-4688
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4688
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.32.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> In Artemis, messages expire by their individual message setting. With some
> variations possible via address settings in the broker configuration.
> But unused subscription-queues are never removed, except for the non-durable
> ones.
> Request is to add a idle-timeout for queues from durable subscriptions. The
> subscription and its queue should then be deleted when there are no
> subscribers during a given time-period.
> I believe ActiveMQ Classic has this via the offlineDurableSubscriberTimeout
> setting, see also
> https://activemq.apache.org/components/classic/documentation/manage-durable-subscribers.
>
> This subject was also mentioned a while back in
> [https://stackoverflow.com/questions/56115426/apache-activemq-artemis-durable-subscription-ttl;]
> but, for our use-cases, using only message-expiry is not sufficient. this is
> because each abandonned durable subscription still stores messages, and is
> thus using resources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4688) add idle subscription removal after timeout
[
https://issues.apache.org/jira/browse/ARTEMIS-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877566#comment-17877566
]
Justin Bertram commented on ARTEMIS-4688:
-
I think you can do this by setting something like this:
{code:xml}
true
-1
6{code}
This will auto-delete queues regardless of how many messages they contain once
no consumers have been connected for 1 minute.
> add idle subscription removal after timeout
> ---
>
> Key: ARTEMIS-4688
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4688
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.32.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> In Artemis, messages expire by their individual message setting. With some
> variations possible via address settings in the broker configuration.
> But unused subscription-queues are never removed, except for the non-durable
> ones.
> Request is to add a idle-timeout for queues from durable subscriptions. The
> subscription and its queue should then be deleted when there are no
> subscribers during a given time-period.
> I believe ActiveMQ Classic has this via the offlineDurableSubscriberTimeout
> setting, see also
> https://activemq.apache.org/components/classic/documentation/manage-durable-subscribers.
>
> This subject was also mentioned a while back in
> [https://stackoverflow.com/questions/56115426/apache-activemq-artemis-durable-subscription-ttl;]
> but, for our use-cases, using only message-expiry is not sufficient. this is
> because each abandonned durable subscription still stores messages, and is
> thus using resources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5018) Eliminate deprecated use of Class.newInstance
Justin Bertram created ARTEMIS-5018: --- Summary: Eliminate deprecated use of Class.newInstance Key: ARTEMIS-5018 URL: https://issues.apache.org/jira/browse/ARTEMIS-5018 Project: ActiveMQ Artemis Issue Type: Task Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4692) Allow export of specific queues
[
https://issues.apache.org/jira/browse/ARTEMIS-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4692:
Description:
Allow export of specific queue(s) using the [{{data exp}}
command|https://activemq.apache.org/components/artemis/documentation/latest/using-cli.html].
In our case we usually only want "DLQ".
was:
Feature request:
Allow export of specific queue / queues using the data exp cli
In our case we usually only want to DLQ.
[https://activemq.apache.org/components/artemis/documentation/latest/using-cli.html]
> Allow export of specific queues
> ---
>
> Key: ARTEMIS-4692
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4692
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Roy Cohen
>Priority: Minor
>
> Allow export of specific queue(s) using the [{{data exp}}
> command|https://activemq.apache.org/components/artemis/documentation/latest/using-cli.html].
> In our case we usually only want "DLQ".
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4782) ActiveMQConnectionFactory - Add getBrokerURL method
[
https://issues.apache.org/jira/browse/ARTEMIS-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877471#comment-17877471
]
Justin Bertram commented on ARTEMIS-4782:
-
There is the
{{org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory#toURI}}
method that should serve the same basic purpose. Is this not sufficient?
> ActiveMQConnectionFactory - Add getBrokerURL method
> ---
>
> Key: ARTEMIS-4782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4782
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMS
>Affects Versions: 2.33.0
>Reporter: Claus Ibsen
>Priority: Minor
>
> It would be good to have a getter method for tooling and monitoring systems
> to know what the brokerURL is configured on the connection factory.
> AMQ classic has this, but Artemis does not.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-3574) Allow multiple bindings for embedded webserver
[ https://issues.apache.org/jira/browse/ARTEMIS-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877466#comment-17877466 ] Justin Bertram commented on ARTEMIS-3574: - [~akvel], can you elaborate on your issue? Perhaps it would be best to create a new issue with a complete explanation of your problem considering this one is closed. > Allow multiple bindings for embedded webserver > -- > > Key: ARTEMIS-3574 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3574 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > At the moment it is only possible to configure one binding for the embedded > jetty webserver to listen on. It would be great to have the possibility to > configure multiple bindings for different war-files in order to serve those > files on different ports and allow the usage of http and https at the same > time. > My current problem is the usage of the prometheus metrics plugin. In our > setup it is not possible to call the "/metrics" endpoint with SSL enabled. > Therefore I would like to define a second binding without SSL enabled for > this plugin. Disabling SSL completely is not an option as other endpoints > like the jolokia-api and the web-console require some user authentication > which should be protected. > The idea is to move all binding related configuration parameters of the > "web" element and the configured "apps" in "bootstrap.xml" to a new element > called "binding" and put a list of those "binding" elements inside the "web" > element. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4761) Provide JakartaEE 10 supported "artemis-dto" library.
[ https://issues.apache.org/jira/browse/ARTEMIS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4761. - Resolution: Abandoned > Provide JakartaEE 10 supported "artemis-dto" library. > -- > > Key: ARTEMIS-4761 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4761 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.33.0 >Reporter: Varsha >Priority: Major > > Provide JakartaEE 10 supported "artemis-dto" library. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4719) Artemis Metrics plugin reports wrong data
[ https://issues.apache.org/jira/browse/ARTEMIS-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4719. - Resolution: Cannot Reproduce Without a way to reproduce this I don't see how we can proceed with the investigation. > Artemis Metrics plugin reports wrong data > - > > Key: ARTEMIS-4719 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4719 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Mohanavalli A >Priority: Minor > Attachments: 6m peak.png, broker-metrics-plugin.zip, > image-2024-04-10-12-46-10-394.png > > > We are using an Artemis broker metrics plugin to monitor the message count on > each address of the broker. Recently we have noticed that the plugin reported > values which were not realistic and not matching with any of our other > monitoring information available. > !6m peak.png|width=502,height=471! > For a particular address, the plugin reported below values every minute. The > messages count increase from 437k to 5million and 451K to 6million and a fall > from 6M to 462 K are not realistic considering the producer/consumers > capacity. From the values 5M and 6M look to be fake values. > !image-2024-04-10-12-46-10-394.png|width=211,height=429! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4819) Improve user list output in CLI
[
https://issues.apache.org/jira/browse/ARTEMIS-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4819.
-
Resolution: Won't Do
Please see the [discussion on the
PR|https://github.com/apache/activemq-artemis/pull/4980] for further details
about why this won't be done.
> Improve user list output in CLI
> ---
>
> Key: ARTEMIS-4819
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4819
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Vilius Šumskas
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently `artemis user list` command output is not very script friendly. It
> prints users like this:
> {noformat}
> "krttmtr5zh3yx1j"(role_adm_krttmtr5zh3yx1j)
> "wge4qbpzykuqety"(role_adm_wge4qbpzykuqety)
> "8wezkl4yg0wmmcr"(role_adm_8wezkl4yg0wmmcr)
> "atrnohhggvhocqq"(role_adm_atrnohhggvhocqq){noformat}
> My proposal is to split users and roles with a space like this, so that the
> output can be parsed and used in bash scripts more effectively:
> {noformat}
> krttmtr5zh3yx1j (role_adm_krttmtr5zh3yx1j)
> wge4qbpzykuqety (role_adm_wge4qbpzykuqety)
> 8wezkl4yg0wmmcr(role_adm_8wezkl4yg0wmmcr)
> atrnohhggvhocqq (role_adm_atrnohhggvhocqq){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5016) Memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5016: Component/s: (was: ActiveMQ-Artemis-Native) > Memory not getting released > --- > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > Attachments: broker.xml > > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5016) Memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-5016: Summary: Memory not getting released (was: Artemis active MQ memory not getting released) > Memory not getting released > --- > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > Attachments: broker.xml > > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5017) Bridge leaks ClientSessionFactory instance on reconnect attempt
Justin Bertram created ARTEMIS-5017: --- Summary: Bridge leaks ClientSessionFactory instance on reconnect attempt Key: ARTEMIS-5017 URL: https://issues.apache.org/jira/browse/ARTEMIS-5017 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
