[jira] [Closed] (ARTEMIS-1213) Support Client Side Persistence.
[ https://issues.apache.org/jira/browse/ARTEMIS-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-1213. Resolution: Abandoned > Support Client Side Persistence. > > > Key: ARTEMIS-1213 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1213 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Client side persistence allows the client decouple the sending of messages > with the availability of the broker for periods of time. > It does not reduce the HA of the messaging product as for message > failure/loss it would require both client and broker side failures. > It has previously been requested here: > https://developer.jboss.org/thread/48115 > Other brokers have this feature > Oracle: Store-and-Forward Client > https://docs.oracle.com/middleware/1213/wls/SACLT/saf_client.htm#SACLT150 > WebMethods: Client-side-queue > https://www.scribd.com/doc/80485664/Web-Methods-Integration-Server-JMS-Client-Developer-s-Guide-7-1 > Fiorano: Client-side-persistance > http://www.fiorano.com/products/Enterprise-Messaging/JMS/Java-Message-Service/FioranoMQ-New-Release.php > It could possibly work in two ways: > Circuit-Breaker where client direct sends if circuit is closed, but on > failure circuit is opened and messages are routed to client store, only after > connection re-estabilished and client store is empty the circuit re-closes. > Benefits of this is the client side store is only used in failure scenario as > such latency is not affected. > All messages flow through the client store, send is return to client on > success of sending to store, and subsequent thread is used to drain the store > to the broker. Benefits of this are that the broker send could batch up > message sends or even better could possible async handle the send, improving > throughput. > Ideally this could be an add-on, as in a wrapper factory around the JMS api's > which then could mean its re-use in ActiveMQ5 and also QPID JMS client. -- 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-1965) Exclusive queues don't work from NMS client
[
https://issues.apache.org/jira/browse/ARTEMIS-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-1965.
Resolution: Information Provided
Exclusive Queues are defined in the broker configuration via address setting
{code:java}
true {code}
Clients cannot drive this configuration.
> Exclusive queues don't work from NMS client
> ---
>
> Key: ARTEMIS-1965
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1965
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
> Environment: dotnetcore 2.0 using apache.NMS.ActiveMQ 1.7.2 on
> Windows 10
>Reporter: Ben Sudbury
>Priority: Major
>
> I tried to migrate from ActiveMQ 5.x to Artemis using my existing NMS client
> but was unable to because of problems with Exclusive queues.
> I converted the java example of exclusive queues to c# to be sure and I'm
> sorry to say that this basic test failed.
> I was unable to get message groups working either as a workaround though I
> haven't transposed a test for that.
>
> {code:java}
> ConnectionFactory connectionFactory = new
> ConnectionFactory("tcp://localhost:61616");
>
> // Step 2. Create a JMS Connection
> IConnection connection = connectionFactory.CreateConnection();
>
>
> //Step 3. Create a JMS Session
> ISession session =
> connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
>
> //Step 4. Create a Queue Object
> IQueue queue =
> session.GetQueue("client.side.exclusive.queue?exclusive=true");
>
> //Step 5. Create a JMS producer
> IMessageProducer producer = session.CreateProducer(queue);
>
> //Step 6. Create 2 consumers on the queue
> IMessageConsumer consumer1 = session.CreateConsumer(queue);
> IMessageConsumer consumer2 = session.CreateConsumer(queue);
> IMessageConsumer consumer3 = session.CreateConsumer(queue);
>
> //Step 7. Start the connection
> connection.Start();
>
> //Step 8. send 30 text messages
> IMessage message = session.CreateTextMessage("My Message");
> for (int i = 0; i < 30; i++)
> {
> producer.Send(message);
> }
>
> //Step 9. ensure consumer1 gets first 20
> for (int i = 0; i < 20; i++)
> {
> IMessage consumer1Message =
> consumer1.Receive(TimeSpan.FromSeconds(1));
> if (consumer1Message == null)
> {
> throw new Exception("Example FAILED - 'consumer1' should
> have received 20 messages - ony received " + i+1);
> }
> }
>
> Debug.WriteLine("ExclusiveQueueClientSideExample" + " 'consumer1'
> received 20 messages as expected");
>
> //Step 10. ensure consumer2 gets no messages yet!
> IMessage consumer2Message =
> consumer2.Receive(TimeSpan.FromSeconds(1));
> if (consumer2Message != null) {
> throw new Exception("Example FAILED - 'consumer2' should have
> not received any Messages yet!");
> }
>
> //Step 11. close consumer1
> consumer1.Close();
>
> //Step 12. ensure consumer2 receives remaining messages
> for (int i = 0; i< 10; i++) {
> consumer2Message =
> consumer2.Receive(TimeSpan.FromMilliseconds(500));
> if (consumer2Message == null) {
> throw new Exception("Example FAILED - 'consumer2' should
> have received 10 messages" + "after consumer1 has been closed");
> }
> }
>
> Debug.WriteLine("ExclusiveQueueClientSideExample" + " 'consumer2'
> received 10 messages " + "as expected, after 'consumer1' has been closed");
>
> //Step 13. ensure consumer3 gets no messages yet!
> IMessage consumer3Message =
> consumer3.Receive(TimeSpan.FromMilliseconds(500));
> if (consumer3Message != null) {
> throw new Exception("Example FAILED - 'consumer3' should have not
> received any Messages yet!");
> }
>
> Debug.WriteLine("ExclusiveQueueClientSideExample" + " 'consumer3'
> received 0 messages " + "as expected");
> {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] [Closed] (ARTEMIS-2266) large message lost with divert
[
https://issues.apache.org/jira/browse/ARTEMIS-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-2266.
Resolution: Incomplete
The tools used to produce the issue were never provided.
> large message lost with divert
> --
>
> Key: ARTEMIS-2266
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2266
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Jigar Parekh
>Priority: Major
>
> I have following queue setup in cluster
> {code:java}
>
>
> RF-IT
> RFTopic
> IT-InputQueue
> false
>
>
> RF-MO
> RFTopic
> RFInputQueue
> false
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> server1 running on 61616 and server2 running of 61626
> I start two consumer with two different available master server
> {code:java}
> java -jar AmqJmsConsumejar -duration 5 -queue IT-InputQueue -stats -log
> /tmp/artemis/4 -verify -commitdelay 300 -url 'tcp://localhost:61626'
> java -jar AmqJmsConsumejar -duration 5 -queue IT-InputQueue -stats -log
> /tmp/artemis/4 -verify -commitdelay 300 -url 'tcp://localhost:61616' {code}
> and run producer to server1 as below
> {code:java}
> java -jar AmqJmsProducer.jar -topic RFTopic -stats -log /tmp/artemis/4 -id
> -count 500 -n 500 -ttl 360 -url 'tcp://localhost:61616' -outliers 100
> -outliersize 500k {code}
> both consumer gets few message but after below exception server1 clears
> queue with almost 50% of messages but rest of messages are stuck with
> internal.sf.cluster queue and not received by any consumer.
> {noformat}
> java.lang.IllegalStateException: no queueIDs defined
> at
> org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.beforeForward(ClusterConnectionBridge.java:180)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.handle(BridgeImpl.java:609)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2983)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2334)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3209)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> [rt.jar:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> [rt.jar:1.8.0_191]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> 2019-01-08 15:15:33,668 WARN
> [org.apache.activemq.artemis.core.server.impl.QueueImpl] null:
> java.util.NoSuchElementException
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:172)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2353)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3209)
>
> [artemis-server-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
>
> [artemis-commons-2.6.3.jar:2.6.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> [rt.jar:1.8.0_191]
> at
> java.ut
[jira] [Closed] (ARTEMIS-3869) large messages that are blocked still result in orphan files on disk
[ https://issues.apache.org/jira/browse/ARTEMIS-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-3869. Resolution: Cannot Reproduce Tried to reproduce but could not. Reopen if a test again current broker release can be created. > large messages that are blocked still result in orphan files on disk > > > Key: ARTEMIS-3869 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3869 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.20.0 >Reporter: D vd Broek >Priority: Minor > > When an address is blocked using the Block operation (or maybe also other > flow control options) and a producer sends large messages then large messages > files are created with size 0. These empty files remain and are not removed > when purging the queue. (there are no messages on queue). These files seem > orphaned. > When an address is blocking we want to avoid using resources in artemis and > with large number of messages these leads to large number of empty files > which need to be deleted manually. (or that is what we do) -- 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-3728) Failed to deliver: java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-3728.
--
Resolution: Cannot Reproduce
This is quite possibly related to fixes in
https://issues.apache.org/jira/browse/ARTEMIS-5038 which applies to mirroring
as eluded to in some of the comments, I'd recommend testing with v2.38.0 once
it is released.
> Failed to deliver: java.lang.NullPointerException
> -
>
> Key: ARTEMIS-3728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3728
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0, 2.35.0
> Environment: centos 7
> Corretto JDK 11
> Artemis 2.20.0 (with epoll module)
>
>Reporter: Stephen Baker
>Priority: Minor
> Attachments: artemis-1.profile-artms1, broker-1.xml-artms1
>
>
> Seeing the following error in the logs on one of our artemis servers
> repeatedly since last night:
> {noformat}
> 2022-03-17 00:02:20,434 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224041: Failed to deliver: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.utils.collections.LinkedListImpl.addTail(LinkedListImpl.java:141)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl.addTail(PriorityLinkedListImpl.java:84)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.internalAddTail(QueueImpl.java:2877)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.doInternalPoll(QueueImpl.java:2938)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2963)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4205)
> [artemis-server-2.20.0.jar:2.20.0]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.20.0.jar:]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.20.0.jar:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.20.0.jar:]{noformat}
> I don't know how it started or how to reproduce, but I can say that we
> switched to dual mirroring last night per the [current
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html].
> In the process we renamed our mirrors (before they had the same name on each
> side), and deleted the old mirror queues through the management console after
> all of the servers were up. We did this on 4 other pairs (all separate
> clusters) without running into this issue.
> These errors are coming only from the live server on the disaster recovery
> site, which has no consumers except the mirror connection.
> Prior to these errors we did have:
> {noformat}
> 2022-03-16 23:52:29,482 WARN
> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget]
> Queue $ACTIVEMQ_ARTEMIS_MIRROR_Mirror not found on mirror target, ignoring
> ack for queue=$ACTIVEMQ_ARTEMIS_MIRROR_Mirror, messageID=63165878649,
> nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2{noformat}
> in our logs, where that mirror name is the old shared mirror name (not part
> of the current broker.xml).
> Error does not appear to have come back on a restart of the server.
--
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-5043) Bump log4j.version from 2.23.1 to 2.24.0
[ https://issues.apache.org/jira/browse/ARTEMIS-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5043. -- Fix Version/s: 2.38.0 Resolution: Fixed > Bump log4j.version from 2.23.1 to 2.24.0 > > > Key: ARTEMIS-5043 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5043 > 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-5065) We should remove mirror properties for Core and OpenWire Protocols upon receiving them on the server
[ https://issues.apache.org/jira/browse/ARTEMIS-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5065. -- Resolution: Fixed > We should remove mirror properties for Core and OpenWire Protocols upon > receiving them on the server > > > Key: ARTEMIS-5065 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5065 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > > say a consumer received a message from a target mirror using Core or OpenWire > Protocol. > The message will contain properties that would be hidden if using AMQP > Protocol. > Upon receiving them the server should remove them to avoid retagging them > with the older 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-5068) Temporary Queues should not be mirrored
[ https://issues.apache.org/jira/browse/ARTEMIS-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5068. -- Fix Version/s: 2.38.0 Resolution: Fixed > Temporary Queues should not be mirrored > --- > > Key: ARTEMIS-5068 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5068 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >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-4834) Support consuming messages forever with CLI
[ https://issues.apache.org/jira/browse/ARTEMIS-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4834: - Fix Version/s: 2.38.0 > Support consuming messages forever with CLI > --- > > Key: ARTEMIS-4834 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4834 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 50m > 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-4834) Support consuming messages forever with CLI
[ https://issues.apache.org/jira/browse/ARTEMIS-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4834. -- Resolution: Fixed > Support consuming messages forever with CLI > --- > > Key: ARTEMIS-4834 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4834 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 50m > 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-5078) Support divert management via JSON
[ https://issues.apache.org/jira/browse/ARTEMIS-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5078. -- Fix Version/s: 2.38.0 Resolution: Fixed > Support divert management via JSON > -- > > Key: ARTEMIS-5078 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5078 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > -- 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-5085) Use retry parameters on initial connection
[
https://issues.apache.org/jira/browse/ARTEMIS-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-5085.
--
Fix Version/s: 2.38.0
Resolution: Fixed
> Use retry parameters on initial connection
> --
>
> Key: ARTEMIS-5085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
>
> Currently the {{retryInterval}} is applied when attempting the initial
> connection from the Core client to the broker. However,
> {{retryIntervalMultiplier}} and {{maxRetryInterval}} are not. These
> parameters are only applied to reconnect attempts. Both
> {{retryIntervalMultiplier}} and {{maxRetryInterval}} should be applied to the
> initial connection just like {{retryInterval}}.
--
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-5039) Bump netty.version to 4.1.114.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5039. -- Resolution: Fixed > Bump netty.version to 4.1.114.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] [Updated] (ARTEMIS-5039) Bump netty.version to 4.1.114.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-5039: - Summary: Bump netty.version to 4.1.114.Final (was: Bump netty.version to 4.1.113.Final) > Bump netty.version to 4.1.114.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] [Reopened] (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 ] Timothy A. Bish reopened ARTEMIS-5039: -- > 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] [Closed] (ARTEMIS-2252) Intermittent thread deadlock when using message groups and message selectors
[ https://issues.apache.org/jira/browse/ARTEMIS-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2252. Resolution: Cannot Reproduce No test attached to attempt to reproduce, many fixes since the reported release which could have likely solved any issue here > Intermittent thread deadlock when using message groups and message selectors > > > Key: ARTEMIS-2252 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2252 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.4 >Reporter: Leo Provido >Priority: Major > Attachments: Artemis 2.6.4 thread dump.txt > > > We’ve encountered what we think is a bug in Artemis. The issue arises > establishing two AMQP receiver links to the same Artemis queue (durable), > where each receiver link is established with an AMQP “filter set”, and then > messages are sent to the queue where those messages are assigned to message > groups. The messages are filtered on message type (JMSType). With this setup, > we occasionally find that Artemis permanently holds onto a message (i.e. > never delivers it). > We send 100,000 messages (of the same type – all messages go to the same > receiver link) to the queue, where each message is assigned to one of 10,000 > message groups, where each message group contains 10 messages. Furthermore, > the messages are assigned to message groups in the order such that: > • After the first 10,000 messages have been sent, each message group has > been assigned one message > • After the second 10,000 messages have been sent, each message group has > been assigned two messages > • After 90,000 message have been sent, each message group has been > assigned 9 messages. > The client application creating the two receiver links accepts all messages > in a message group when the last message in that message group is received. > We find the client application sometimes receives fewer than 100,000 messages > from Artemis. Around 1 in 3 the application receives 99,999 messages, but > sometimes, even fewer than 99,999 messages. After 2 minutes, we time out the > message group containing the one missing message and reject the 9 messages we > did receive. This then leaves one message in the queue. > This message is never delivered. However, more interestingly, when we then > attempt to close the connection, it takes 60 seconds to close. Furthermore, > after 30 seconds, Artemis logs a thread dump. After another 30 seconds, > Artemis logs a second thread dump, and then the connection is closed. The > attached is a copy of both thread dumps. > Note that if the second receiver link is not created, the issue does not > 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] [Resolved] (ARTEMIS-5072) Support non-paged management results
[ https://issues.apache.org/jira/browse/ARTEMIS-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5072. -- Fix Version/s: 2.38.0 Resolution: Fixed > Support non-paged management results > > > Key: ARTEMIS-5072 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5072 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > > A handful of management methods can return paged results. However, sometimes > it would be simpler to return all of the results in a single page regardless > of the size. -- 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-5075) Support NOT_EQUALS operator to filter some management results
[
https://issues.apache.org/jira/browse/ARTEMIS-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-5075.
--
Fix Version/s: 2.38.0
Resolution: Fixed
> Support NOT_EQUALS operator to filter some management results
> -
>
> Key: ARTEMIS-5075
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5075
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
>
> A handful of management methods support an option syntax for filtering and
> pagination. It would be useful if these methods support a {{NOT_EQUALS}}
> operator.
--
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-5070) Improve management docs
[ https://issues.apache.org/jira/browse/ARTEMIS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5070. -- Fix Version/s: 2.38.0 Resolution: Fixed > Improve management docs > --- > > Key: ARTEMIS-5070 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5070 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > > It would be useful to have some more complex Jolokia examples and also > documentation on the option syntax used by some of the management operations. -- 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-5071) Align naming for management option syntax
[ https://issues.apache.org/jira/browse/ARTEMIS-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5071. -- Fix Version/s: 2.38.0 Resolution: Fixed > Align naming for management option syntax > - > > Key: ARTEMIS-5071 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5071 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > > The JSON string passed to various management methods for filtering uses > disparate names. For example, it uses the name _field_ and _sortColumn_. One > of these should be renamed to match the other. For example, use _field_ and > _sortField_. -- 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-5062) ClusterConnectionControl has wrong annotation
[
https://issues.apache.org/jira/browse/ARTEMIS-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-5062.
--
Fix Version/s: 2.38.0
Resolution: Fixed
> ClusterConnectionControl has wrong annotation
> -
>
> Key: ARTEMIS-5062
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5062
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: management
>Affects Versions: 2.37.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ClusterConnectionControl.getBridgeMetrics() method is annotated with
> {{@Attribute}} but it should be {{@Operation}}.
--
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-5063) Addition of a messageMoved() callback in ActiveMQServerMessagePlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5063. -- Fix Version/s: 2.38.0 Resolution: Fixed > Addition of a messageMoved() callback in ActiveMQServerMessagePlugin > > > Key: ARTEMIS-5063 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5063 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Jean-Pascal Briquet >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The Addition of a messageMoved() callback in ActiveMQServerMessagePlugin > would allow the interception of message move events in custom plugins. > A typical use case would be to log details about these move operations. > > The callback would be triggered when a message move operation occurs within > Artemis. > The best location for this seems to be within the QueueImpl.move() method. > -- 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-5074) Broker AMQP Message mishandles put and get of byte[] in ApplicationProperties
Timothy A. Bish created ARTEMIS-5074: Summary: Broker AMQP Message mishandles put and get of byte[] in ApplicationProperties Key: ARTEMIS-5074 URL: https://issues.apache.org/jira/browse/ARTEMIS-5074 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.37.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.38.0 When the internal AMQPMessage API methods for getting or setting byte[] values in the ApplicationProperties of the AMQP message are used they are treating the value as a byte[] array where it should always be wrapped in an AMQP Binary instance to allow proton to encode it and unwrap it when decoded and fetched from the application properties. Without the handling the proton encoder will throw a ClassCastException when attempting to encode byte[] instances. The get code must account for the Binary as the wrapper and account for the fact that the array may be an offset view of a larger array value. -- 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
]
Timothy A. Bish updated ARTEMIS-5054:
-
Fix Version/s: 2.38.0
(was: 2.31.2)
> large messages only forwarded to one subscriber when using STOMP on multicast
> address
> -
>
> Key: ARTEMIS-5054
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5054
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
>Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0, 2.37.0
>Reporter: Renaud Rwemalika
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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.runWorke
[jira] [Assigned] (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
]
Timothy A. Bish reassigned ARTEMIS-5054:
Assignee: Timothy A. Bish (was: Justin Bertram)
> large messages only forwarded to one subscriber when using STOMP on multicast
> address
> -
>
> Key: ARTEMIS-5054
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5054
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
>Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0, 2.37.0
>Reporter: Renaud Rwemalika
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.31.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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(U
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17884059#comment-17884059
]
Timothy A. Bish commented on ARTEMIS-5054:
--
I took a look and from what I can gather it seems that on write of the outgoing
message to the Stomp connection the frame is created and filled using the body
buffer of a Core message which can happen concurrently for connections from two
Stomp clients leading to the issue with large messages where the body is stored
in a file and a LargeBodyReader is used to grant access to those contents, it
seems that the reader will be shared then between those to threads and when one
reads while another is reading the state becomes invalid and you can fail in
odd ways.
> large messages only forwarded to one subscriber when using STOMP on multicast
> address
> -
>
> Key: ARTEMIS-5054
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5054
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
>Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0, 2.37.0
>Reporter: Renaud Rwemalika
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.2
>
>
> 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
[jira] [Resolved] (ARTEMIS-5058) Update Qpid protonj2 to version 1.0.0-M22
[ https://issues.apache.org/jira/browse/ARTEMIS-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5058. -- Resolution: Fixed > Update Qpid protonj2 to version 1.0.0-M22 > - > > Key: ARTEMIS-5058 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5058 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: AMQP >Affects Versions: 2.37.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 0.5h > 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-5058) Update Qpid protonj2 to version 1.0.0-M22
Timothy A. Bish created ARTEMIS-5058: Summary: Update Qpid protonj2 to version 1.0.0-M22 Key: ARTEMIS-5058 URL: https://issues.apache.org/jira/browse/ARTEMIS-5058 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: AMQP Affects Versions: 2.37.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.38.0 -- 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-5049) Add detailed logging for auth caches
[ https://issues.apache.org/jira/browse/ARTEMIS-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5049. -- Fix Version/s: 2.38.0 Resolution: Fixed > 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 >Priority: Major > Fix For: 2.38.0 > > Time Spent: 40m > 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-2748) Support websockets compression
[ https://issues.apache.org/jira/browse/ARTEMIS-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883109#comment-17883109 ] Timothy A. Bish commented on ARTEMIS-2748: -- This can be tested using protonj2 once the upcoming v1.0.0-M22 release is finalized, the commit with some tests showing how this is enabled and tested is [here|https://github.com/apache/qpid-protonj2/commit/e9de35dc] > Support websockets compression > -- > > Key: ARTEMIS-2748 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2748 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: STOMP >Affects Versions: 2.12.0 >Reporter: Top Kool >Assignee: Justin Bertram >Priority: Minor > Attachments: test-ws-compression.js > > > We use Artemis for clients from internet, and most of them have really > limited bandwidth while connecting to Artemis through STOMP. Thus, native > support of websockets compression would be very helpful. -- 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-3915) Support Proxy protocol (HAProxy) on Artemis acceptors
[ https://issues.apache.org/jira/browse/ARTEMIS-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-3915. Resolution: Abandoned There has been no movement from the original requestor on fixing issues requested in the original PR, closing as abandoned > Support Proxy protocol (HAProxy) on Artemis acceptors > - > > Key: ARTEMIS-3915 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3915 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: João Santos >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > [HAProxy|http://www.haproxy.org/] is a widely known and used TCP Load > Balancer and especially useful for an ActiveMQ Artemis clustered environment. > Although possible to functionally implement with both products current > features, Artemis does not support the PROXY protocol, which prevents it's > broker nodes from inferring the real remote client IP address when behind an > HAProxy instance. > Since Netty sockets implementation already seems to support this protocol > (discussed w/ [~jbertram] on DEV mailing list), it shouldn't be a big leap to > adding support for the protocol on Artemis acceptors, thus improving the > deployment of the use case at hand. -- 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-5052) Hash authentication cache keys
[ https://issues.apache.org/jira/browse/ARTEMIS-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-5052. -- Resolution: Fixed > 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 >Priority: Major > Fix For: 2.38.0 > > Time Spent: 50m > 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-5052) Hash authentication cache keys
[ https://issues.apache.org/jira/browse/ARTEMIS-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-5052: - Fix Version/s: 2.38.0 > 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 >Priority: Major > Fix For: 2.38.0 > > Time Spent: 50m > 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-5032) Message priority not honored for persisted AMQP messages after server restarted
[ https://issues.apache.org/jira/browse/ARTEMIS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-5032: - Summary: Message priority not honored for persisted AMQP messages after server restarted (was: Message priority not honored to persisted AMQP messages after server restarted) > Message priority not honored for persisted AMQP messages after server > restarted > --- > > Key: ARTEMIS-5032 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5032 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.37.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.38.0 > > > Messages sent with a non-default priority level that are persisted and later > recovered after a server restart do not get delivered according to their > original message priority but are all treated as having the default priority > value (priority 4). -- 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-5032) Message priority not honored to persisted AMQP messages after server restarted
Timothy A. Bish created ARTEMIS-5032: Summary: Message priority not honored to persisted AMQP messages after server restarted Key: ARTEMIS-5032 URL: https://issues.apache.org/jira/browse/ARTEMIS-5032 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.37.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.38.0 Messages sent with a non-default priority level that are persisted and later recovered after a server restart do not get delivered according to their original message priority but are all treated as having the default priority value (priority 4). -- 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-5012) Update docs & code to clarify resource-limit-settings
[
https://issues.apache.org/jira/browse/ARTEMIS-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-5012.
--
Fix Version/s: 2.38.0
Resolution: Fixed
> Update docs & code to clarify resource-limit-settings
> -
>
> Key: ARTEMIS-5012
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5012
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently the docs & code refer to the {{max-connections}}
> {{resource-limit-setting}}, but what's really being limited here is
> _sessions_, not connections. The docs & code should be changed to clarify
> this.
--
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-4978) JMX message replay from retention cannot find AMQP messages when using filters
[ https://issues.apache.org/jira/browse/ARTEMIS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877139#comment-17877139 ] Timothy A. Bish commented on ARTEMIS-4978: -- Initial comment on the attached test is that it is incorrectly assuming that the JMS MessageProducer will apply message priority set on the message via *message.setJMSPriority(N)* which is specifically called out in the JMS API docs as not supported (although it seems like Core applies that value in error). So you should update your test to use the message producer *producer.setPriority(N)* instead. > JMX message replay from retention cannot find AMQP messages when using filters > -- > > Key: ARTEMIS-4978 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4978 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, JMX, management >Affects Versions: 2.36.0 >Reporter: Jean-Pascal Briquet >Priority: Minor > Attachments: ReplayTest.java > > > Attempting to recover messages with replay and filters fails to find AMQP > messages. > The following message properties used in filter do not match AMQP messages in > retention files : AMQTimestamp, AMQPriority, ... which cause the replay > process to be unable to restore the message. > > To reproduce, I have enhanced the existing message replay test case to verify > filter behaviour. > To run it, just replace the existing Artemis test class located in > "tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/retention" > with the provided one. > -- 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-5007) Mirroring consumer does not recover automatically
[
https://issues.apache.org/jira/browse/ARTEMIS-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-5007:
-
Affects Version/s: 2.37.0
> Mirroring consumer does not recover automatically
> -
>
> Key: ARTEMIS-5007
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5007
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.36.0, 2.37.0
>Reporter: Jean-Pascal Briquet
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.38.0
>
> Attachments: testBrokerMirrorRecreateConsumer.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Context:*
> AMQP broker connection and mirroring link enabled between two Artemis nodes
> *Current behaviour:*
> The mirroring consumer does not recover automatically when it is closed from
> the administration console/JMX, or if the consumer crashes.
> This behaviour differs from the AMQP broker connection that is able to
> recover automatically if connection is closed or if connectivity fails.
> *Workaround:*
> Close the AMQP broker connection that was used by the mirroring consumer. The
> broker connection will be recreated automatically, starting a new mirroring
> consumer and restoring the replication.
> *Expected behaviour:*
> If the AMQP broker connection is active, the mirroring consumer should always
> restart if it stops or if it crashes. And at most one consumer should be
> present on the mirror/snf queue.
> This would provide to consumer a recovery identical to the AMQP broker
> connection's self-healing feature.
>
> *Tests cases:*
> Test cases are provided in attachment, to run, add them into the Artemis test
> class located under:
> tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/AMQPReplicaTest.java
> * {color:#00627a}testBrokerMirrorRecreateConsumer() : consumer closed and is
> never recreated automically{color}
> * {color:#00627a}testBrokerMirrorRecreateConnection() : broker connection
> closed and automatically recreated. The strange thing is that there is a low
> chance (10-20%) this test fails because more than 1 consumer will exists on
> the snf queue after the reconnection.
> {color}
>
--
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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-4970.
Resolution: Information Provided
Closing this as the root cause has been identified as the interceptor modifying
outgoing messages leading to concurrent access issues. For other behaviours
discussed here that might still be of concern please open a new JIRA with steps
to reproduce
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
> Attachments: MessagePropertiesInjector.java, ioob-reload-core.log,
> ioob-target-mirror-props.log
>
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-classes-epoll-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.36.0.jar:2.36.0]
> 2024-08-06 03:44:00,596 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
> [address=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-1,
> queue=QueueImpl[name=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-1,
> post
[jira] [Commented] (ARTEMIS-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875544#comment-17875544
]
Timothy A. Bish commented on ARTEMIS-4970:
--
>From a review of the code the issue could only have been that the message was
>being concurrently modified. I don't see any clear path to protecting the
>various routes the message can take from an interceptor causing this kind of
>corruption which is why I'd generally say modifications should on be done on
>incoming ones.
The second issue seems like it might be unrelated to this so might warrant
another issue so that you can more succinctly define that case and how to test
/ reproduce it.
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
> Attachments: MessagePropertiesInjector.java, ioob-reload-core.log,
> ioob-target-mirror-props.log
>
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-classes-epoll-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.36.0.jar:2.36.0]
> 2024-08-06 03:44:00,596 WARN [org.apache.activemq.arte
[jira] [Created] (ARTEMIS-5004) AMQP Federation address bindings could be cleaned up faster
Timothy A. Bish created ARTEMIS-5004: Summary: AMQP Federation address bindings could be cleaned up faster Key: ARTEMIS-5004 URL: https://issues.apache.org/jira/browse/ARTEMIS-5004 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.37.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.38.0 When an AMQP Federation address consumer is closed because the local broker no longer has demand the binding on the remote address can be removed immediately as opposed to waiting on a scheduled cleanup. -- 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-4998) AMQP Federation target can close connection in error
Timothy A. Bish created ARTEMIS-4998: Summary: AMQP Federation target can close connection in error Key: ARTEMIS-4998 URL: https://issues.apache.org/jira/browse/ARTEMIS-4998 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.37.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.38.0 When headlining link closures from the source federation broker the target can decide in error to close the connection when links from the source are closed because local demand was removed, this causes an unneeded federation rebuild. -- 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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874267#comment-17874267
]
Timothy A. Bish commented on ARTEMIS-4970:
--
My original suggestion was off a little as it should also add the data section
header bytes to the encode size. I've not been able to reproduce this or see
where it could get into this situation so I might just add this if you report
that it has solved the situation for you. It could be your interceptors are
putting the core message into an odd state but I can't figure out without more
information what that might be.
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-classes-epoll-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.36.0.jar:2.36.0]
> 2024-08-06 03:44:00,596 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
> [address=$ACTIVEMQ_ARTEMIS_MI
[jira] [Comment Edited] (ARTEMIS-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873028#comment-17873028
]
Timothy A. Bish edited comment on ARTEMIS-4970 at 8/16/24 2:16 PM:
---
Short of having a reproducer I can only guess. I would start by digging deeper
into the difference between the working and non-working case although I don't
think Netty logging or Netty itself is the issue, probably something in the
Core message and or the ActiveMQBuffer that it uses is resulting in the error.
Another thing to try would be to ensure after writing any delivery annotations
that the target buffer is right sized once again for the pending persist by
modifying the block to something like this:
{code:java}
final DeliveryAnnotations annotations =
messageReference.getProtocolData(DeliveryAnnotations.class);
if (annotations != null && annotations.getValue() != null &&
annotations.getValue().size() > 0) {
final EncoderImpl encoder = TLSEncode.getEncoder();
try {
encoder.setByteBuffer(new NettyWritable(buffer));
encoder.writeObject(annotations);
} finally {
encoder.setByteBuffer((WritableBuffer) null);
}
buffer.ensureWritable(encodedSize + DATA_SECTION_ENCODING_BYTES);
// Right size the target buffer
}
{code}
was (Author: tabish121):
Short of having a reproducer I can only guess. I would start by digging deeper
into the difference between the working and non-working case although I don't
think Netty logging or Netty itself is the issue, probably something in the
Core message and or the ActiveMQBuffer that it uses is resulting in the error.
Another thing to try would be to ensure after writing any delivery annotations
that the target buffer is right sized once again for the pending persist by
modifying the block to something like this:
{code:java}
final DeliveryAnnotations annotations =
messageReference.getProtocolData(DeliveryAnnotations.class);
if (annotations != null && annotations.getValue() != null &&
annotations.getValue().size() > 0) {
final EncoderImpl encoder = TLSEncode.getEncoder();
try {
encoder.setByteBuffer(new NettyWritable(buffer));
encoder.writeObject(annotations);
} finally {
encoder.setByteBuffer((WritableBuffer) null);
}
buffer.ensureWritable(encodedSize); // Right size the target buffer
}
{code}
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
>
[jira] [Resolved] (ARTEMIS-4985) Message priority occasionally broken
[ https://issues.apache.org/jira/browse/ARTEMIS-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4985. -- Fix Version/s: 2.37.0 Resolution: Fixed > Message priority occasionally broken > > > Key: ARTEMIS-4985 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4985 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes a lower priority message may be dispatched before a higher priority > message. -- 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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873028#comment-17873028
]
Timothy A. Bish commented on ARTEMIS-4970:
--
Short of having a reproducer I can only guess. I would start by digging deeper
into the difference between the working and non-working case although I don't
think Netty logging or Netty itself is the issue, probably something in the
Core message and or the ActiveMQBuffer that it uses is resulting in the error.
Another thing to try would be to ensure after writing any delivery annotations
that the target buffer is right sized once again for the pending persist by
modifying the block to something like this:
{code:java}
final DeliveryAnnotations annotations =
messageReference.getProtocolData(DeliveryAnnotations.class);
if (annotations != null && annotations.getValue() != null &&
annotations.getValue().size() > 0) {
final EncoderImpl encoder = TLSEncode.getEncoder();
try {
encoder.setByteBuffer(new NettyWritable(buffer));
encoder.writeObject(annotations);
} finally {
encoder.setByteBuffer((WritableBuffer) null);
}
buffer.ensureWritable(encodedSize); // Right size the target buffer
}
{code}
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
>
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
>
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {code:java}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-c
[jira] [Created] (ARTEMIS-4982) AMQP Large message files not removed immediately on failed sends
Timothy A. Bish created ARTEMIS-4982: Summary: AMQP Large message files not removed immediately on failed sends Key: ARTEMIS-4982 URL: https://issues.apache.org/jira/browse/ARTEMIS-4982 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.36.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.37.0 When an incoming large message is rejected for any reason the large message file is not cleaned up immediately as it should be. -- 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-4963) Reject openwire senders that lack SEND permissions on attach
[ https://issues.apache.org/jira/browse/ARTEMIS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4963. -- Fix Version/s: 2.37.0 Resolution: Fixed > Reject openwire senders that lack SEND permissions on attach > > > Key: ARTEMIS-4963 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4963 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.36.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.37.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently the Openwire producers are allowed to attach even when the named > destination(s) it requests don't offer send permissions to the logged in user > (the sends themselves are validated). The sends from these named or from > anonymous producers are checked for permission but only after such things as > conversion of the message to Core has happened which leads to unnecessary GC > overhead and wasted CPU cycles if the send is going to ultimately be > rejected. > We should reject Openwire senders on attach (which is what the ActiveMQ > 'Classic' broker does) and we should check send permissions prior to > unnecessarily converting messages to Core to reduce overhead from anonymous > senders that are sending into destinations they cannot write to. This change > doesn't introduce any new security but simply would respond more quickly and > efficiently than the current code would. -- 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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871142#comment-17871142
]
Timothy A. Bish commented on ARTEMIS-4970:
--
Some way to reproduce this would be beneficial, however you can disabled core
tunneling in your XML configuration using something like the following to try
and work around the issue:
{code:xml}
{code}
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
>
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
>
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {code:java}
> 2024-08-02 22:01:46,056 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
> [address=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-1,
> queue=QueueImpl[name=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-1,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=artemis-dc1-primary-1],
> temp=false]@1f5af8e5, filter=null, name=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-1,
> clusterName=$ACTIVEMQ_ARTEMIS_MIRROR_dc2-group-154a6ae45-26e5-11ee-837c-506b8d97040b],
> closed=false],
> message=Reference[279848883113]:RELIABLE:CoreMessage[messageID=279848883113,
> durable=true, userID=565b82e5-513c-11ef-aaa1-fe3d2d71403d, priority=4,
> timestamp=Fri Aug 02 22:01:46 EDT 2024, expiration=0, durable=true,
> address=queue.ua.release.shared.events.payment-services.internal, size=3071,
> properties=TypedProperties[traceparent=00-2630f625064718026d4283d98d757d38-052e1857dcc761da-00,
> __AMQ_CID=d519d3e7-50ca-11ef-aaa1-fe3d2d71403d,
> elastic_apm_traceparent=00-2630f625064718026d4283d98d757d38-052e1857dcc761da-00,
> _AMQ_ROUTING_TYPE=1, _BT_MAX_DELIVERY=30,
> JMSCorrelationID=O202408030401340001Q_SEU_SELF-9cd96504-f1df-42d2-8d89-c26e79cb44cd,
> _AMQ_VALIDATED_USER=ACTIVEMQ.CLUSTER.ADMIN.USER]]@1105557896
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 3288
> (expected: 0 <= readerIndex <= writerIndex <= capacity(3083))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.111.Final.jar:4.1.111.Final]
> at
> io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.111.Final.jar:4.1.111.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.35.0.jar:2.35.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.35.0.jar:2.35.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.35.0.jar:2.35.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.35.0.jar:2.35.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.111.Final.jar:4.1.111.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.111.Final.jar:4.1.111.Final]
> at
> io.netty.util.concurrent.SingleThrea
[jira] [Created] (ARTEMIS-4969) FQQN Security settings not honored when an AMQP Sender attaches
Timothy A. Bish created ARTEMIS-4969: Summary: FQQN Security settings not honored when an AMQP Sender attaches Key: ARTEMIS-4969 URL: https://issues.apache.org/jira/browse/ARTEMIS-4969 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.36.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.37.0 When an AMQP sender link is attaching with an FQQN in the target address the initialization code is not checking fully if the sender has specifically granted FQQN access and can fail the attach in error. Instead of just checking the FQQN address portion of the target addres both the FQQN address and queue should be checked with the security store so that the link attach can complete when authorized. This was addressed for Core clients in ARTEMIS-4580 -- 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-4963) Reject openwire senders that lack SEND permissions on attach
Timothy A. Bish created ARTEMIS-4963: Summary: Reject openwire senders that lack SEND permissions on attach Key: ARTEMIS-4963 URL: https://issues.apache.org/jira/browse/ARTEMIS-4963 Project: ActiveMQ Artemis Issue Type: Improvement Components: OpenWire Affects Versions: 2.36.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Currently the Openwire producers are allowed to attach even when the named destination(s) it requests don't offer send permissions to the logged in user (the sends themselves are validated). The sends from these named or from anonymous producers are checked for permission but only after such things as conversion of the message to Core has happened which leads to unnecessary GC overhead and wasted CPU cycles if the send is going to ultimately be rejected. We should reject Openwire senders on attach (which is what the ActiveMQ 'Classic' broker does) and we should check send permissions prior to unnecessarily converting messages to Core to reduce overhead from anonymous senders that are sending into destinations they cannot write to. This change doesn't introduce any new security but simply would respond more quickly and efficiently than the current code would. -- 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-4952) JMX countMessages: groupBy not working on AMQP messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4952.
--
Resolution: Fixed
> JMX countMessages: groupBy not working on AMQP messages
> ---
>
> Key: ARTEMIS-4952
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4952
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMX, management
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Minor
> Fix For: 2.37.0
>
> Attachments: image-2024-07-25-09-54-32-066.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I encountered weird behavior with JMX _countMessages(String, String)_ when
> messages are produced via *AMQP* then moved to another queue and when I call
> *countMessages* operation with a group by
> h2. Context:
> * I create *1600 *messages to *queue.1*, using *CORE* protocol
> * I create *440 *messages to *queue.2*, using *AMQP* protocol
> * I move all messages from *queue.1* to *dl.default* queue, using
> moveMessages operation
> * I move all messages from *queue.2* to *dl.default* queue, using
> moveMessages operation
>
> h2. Current behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"null": 440, "queue.1": 1600}
> {code}
> If I also filter by _ _AMQ_ORIG_QUEUE='queue.2'_ i get
> {code}
> {"null": 440}
> {code}
> !image-2024-07-25-09-54-32-066.png!
>
> h2. Expected behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"queue.2": 440, "queue.1": 1600}
> {code}
> h2. Notes
> I was wondering why
> [message.getObjectProperty|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/QueueControlImpl.java#L1164]
> is called instead of
> [message.getObjectPropertyForFilter|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L237]
> as for filtering
> I did the test using getObjectPropertyForFilter instead of getObjectProperty
> and it works
--
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-4952) JMX countMessages: groupBy not working on AMQP messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4952:
-
Fix Version/s: 2.37.0
> JMX countMessages: groupBy not working on AMQP messages
> ---
>
> Key: ARTEMIS-4952
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4952
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMX, management
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Minor
> Fix For: 2.37.0
>
> Attachments: image-2024-07-25-09-54-32-066.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I encountered weird behavior with JMX _countMessages(String, String)_ when
> messages are produced via *AMQP* then moved to another queue and when I call
> *countMessages* operation with a group by
> h2. Context:
> * I create *1600 *messages to *queue.1*, using *CORE* protocol
> * I create *440 *messages to *queue.2*, using *AMQP* protocol
> * I move all messages from *queue.1* to *dl.default* queue, using
> moveMessages operation
> * I move all messages from *queue.2* to *dl.default* queue, using
> moveMessages operation
>
> h2. Current behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"null": 440, "queue.1": 1600}
> {code}
> If I also filter by _ _AMQ_ORIG_QUEUE='queue.2'_ i get
> {code}
> {"null": 440}
> {code}
> !image-2024-07-25-09-54-32-066.png!
>
> h2. Expected behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"queue.2": 440, "queue.1": 1600}
> {code}
> h2. Notes
> I was wondering why
> [message.getObjectProperty|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/QueueControlImpl.java#L1164]
> is called instead of
> [message.getObjectPropertyForFilter|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L237]
> as for filtering
> I did the test using getObjectPropertyForFilter instead of getObjectProperty
> and it works
--
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-2337) federated queues not working correctly with wildcards or defaults
[ https://issues.apache.org/jira/browse/ARTEMIS-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2337. Resolution: Cannot Reproduce There have been a few big fixes in the core federation layer (especially some wildcard handling changes) that might address this case. We'd need a reproducer for the current release code to validate if any other issue exists. > federated queues not working correctly with wildcards or defaults > - > > Key: ARTEMIS-2337 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2337 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: RHEL >Reporter: Thomas Wood >Priority: Minor > > artemis1 upstream federated to artemis2. > clients consume artemis2 messages from artemis1. > client connects to artemis1 and messages are routed from artemis2 as > expected, but any new messages that land on artemis2 are not routed to > artemis1 until the client reconnects. > It seems that the issue is related to wildcards: > include-federated="false"> > > > The following config works as expected with the client receiving message > prior to and during the life of client connection: > include-federated="false"> > > > also noticed that the following causes the issue too: > include-federated="false"> > > > > but this works: > include-federated="false"> > > > > > > -- 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-4673) Calling removeAnnotation() in a outgoing AMQP interceptor doesn't recalculate message size
[
https://issues.apache.org/jira/browse/ARTEMIS-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868482#comment-17868482
]
Timothy A. Bish commented on ARTEMIS-4673:
--
This is true of modifications of outgoing Core messages as well. I'd say in
general modifying an outgoing message content is a dangerous and not
recommended action on the face of it given the affect it has on the in memory
version of a message.
> Calling removeAnnotation() in a outgoing AMQP interceptor doesn't recalculate
> message size
> --
>
> Key: ARTEMIS-4673
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4673
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.31.2
>Reporter: Tobias Månsson
>Priority: Major
>
>
> The follwoing code is run on outgoing messages, to remove annotations used
> for internal routing.
> {code:java}
> public class Scrub implements InterceptorFunction {
> protected List attributes;
> Scrub(ScrubType scrub) {
> attributes = new ArrayList<>(scrub.getAttributes());
> }
> @Override
> public boolean apply(AMQPMessage amqpMessage) {
> if (amqpMessage.getMessageAnnotations() == null || attributes ==
> null) {
> return;
> }
> attributes.forEach(attribute -> {
> if (amqpMessage.removeAnnotation(new
> SimpleString(Annotator.ANNOTATION_PREFIX + attribute)) != null) {
> amqpMessage.messageChanged();
> }
> });
> return true;
> }
> } {code}
> After this is done, and the message reencoded, delivering size grows with
> each message on the address.
> Some analysis shows that the message size calculation is done before the
> interceptor is done, and that message size then has the wrong value.
> I assume that the deducted value when a message is removed from the
> delivering queue is lower than the previous calculated, leading to the
> growing delivering size metric.
>
--
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-4923) Reduce synchronization in ManagementServiceImpl
[
https://issues.apache.org/jira/browse/ARTEMIS-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4923.
--
Fix Version/s: 2.36.0
Resolution: Fixed
> Reduce synchronization in ManagementServiceImpl
> ---
>
> Key: ARTEMIS-4923
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4923
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The {{ManagementService}} is used by the broker to register and unregister
> components for management as well as send notifications. When the broker is
> busy dealing with new sessions and auto-creating queues, addresses, etc.
> there is a lot of contention in this service. However, much of the
> synchronization can be removed completely or replaced with more efficient
> thread-safe underlying data structures.
--
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-3312) Federated queue not ack message and duplicate
[ https://issues.apache.org/jira/browse/ARTEMIS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-3312. Resolution: Incomplete Not enough information here to attempt a reproducer. Many fixes have occurred since 2.17.0 as well the option to use AMQP federation exists. Reopen if a reproducer on a current release is available. > Federated queue not ack message and duplicate > - > > Key: ARTEMIS-3312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, Federation >Affects Versions: 2.17.0 > Environment: CentOS 7, Java 1.8 oracle (last), java artemis library > (jms listener), artemis 2.17.0 >Reporter: Alexander Andreevich Revkov >Priority: Major > Attachments: artemis_bug_fed.gif, image-2021-05-21-14-53-46-390.png > > > Hello. I have a 3 instances of artemis Cluster (Artemis01 (Master) -> > Artemis02 (Slave) and Artemis03 (standalone). > Artemis01 and Artemis02 have upstream federated queue to Artemis03. I run a > JMS consumer on Artemis01 (Master) TEST.FEDERATED address (ANYCAST). I send > message with producer to Artemis03 TEST.FEDERATE address (ANYCAST). This > message auto delivered with federated queue to my consumer on Artemis01 > (Master) and i ACK this message. After this i kill process of Artemis01 > (Master) with command kill -9 artemis01_pid. My consumer auto reconnect to > slave Artemis02 (Slave) and *MY ACK message* *returned back to Artemis 03!* > Why? If i received this and ack. After message returned back to Artemis03 > federated queue did second delivery this message to my JMS consumer on > Artemis 02 (Slave). I think this is incorrect behaviour. I add gif image with > details. If i not kill artemis 01 process and use command artemis stop then > all work fine and message not returned back and deliver twice! I think this > is bug. Please fix it. > !image-2021-05-21-14-53-46-390.png! -- 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-2277) Message modified with undeliverable-here=true and part of a message group gets stuck in queue
[ https://issues.apache.org/jira/browse/ARTEMIS-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2277. Resolution: Cannot Reproduce Could not reproduce a stuck message in testing this case, would need a valid reproducer to chase more. > Message modified with undeliverable-here=true and part of a message group > gets stuck in queue > - > > Key: ARTEMIS-2277 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2277 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: Windows 10 >Reporter: James Yang Kuang Lim >Priority: Major > > After a message group has been assigned, a consumer modifies one of a message > from that message group with undeliverable-here = true which indicates this > message will not get redelivered to this same consumer. The result is that > message sits in the queue forever. Can this be fixed so that whenever a > message that is part of a message group gets modified with undeliverable-here > = true, that message will get delivered to dead letter queue? -- 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-4938) Update commons-lang to 3.15.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4938. -- Resolution: Fixed > Update commons-lang to 3.15.0 > - > > Key: ARTEMIS-4938 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4938 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: 2.36.0 > > > Update commons-lang to 3.15.0 -- 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-4938) Update commons-lang to 3.15.0
Timothy A. Bish created ARTEMIS-4938: Summary: Update commons-lang to 3.15.0 Key: ARTEMIS-4938 URL: https://issues.apache.org/jira/browse/ARTEMIS-4938 Project: ActiveMQ Artemis Issue Type: Task Components: Tests Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 Update commons-lang to 3.15.0 -- 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-4936) Verify response correlationId in Core client
[
https://issues.apache.org/jira/browse/ARTEMIS-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4936.
--
Fix Version/s: 2.36.0
Resolution: Fixed
> Verify response correlationId in Core client
>
>
> Key: ARTEMIS-4936
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4936
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Consider a Core client sending packets with blocking semantics and a
> confirmationWindowSize >= 0. For example, consider such a client sending
> multiple durable messages in a transaction and then committing that
> transaction. If, for whatever reason, the response for the commit packet is
> never returned it's possible that the call to commit will _still_ succeed.
> This is because {{ChannelImple}} does not verify the correlation ID set on
> the commit packet and will interpret a _previous_ response as the current
> response to the commit.
--
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-4914) Clarify docs on core + client ID
[ https://issues.apache.org/jira/browse/ARTEMIS-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4914. -- Fix Version/s: 2.36.0 Resolution: Fixed > Clarify docs on core + client ID > > > Key: ARTEMIS-4914 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4914 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.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-4920) Strip leading forward slash from IP address
[
https://issues.apache.org/jira/browse/ARTEMIS-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4920.
--
Fix Version/s: 2.36.0
Resolution: Fixed
> Strip leading forward slash from IP address
> ---
>
> Key: ARTEMIS-4920
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4920
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{org.apache.activemq.artemis.spi.core.remoting.Connection#getRemoteAddress}}
> invokes {{toString}} on a {{java.net.SocketAddress}} implementation which
> typically yields a {{String}} like "/x.x.x.x:123". However, this leading
> forward slash character should be stripped to clarify this data in the logs,
> management console, etc.
--
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-4921) Include protocol name in disconnection log message
[
https://issues.apache.org/jira/browse/ARTEMIS-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4921.
--
Fix Version/s: 2.36.0
Resolution: Fixed
> Include protocol name in disconnection log message
> --
>
> Key: ARTEMIS-4921
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4921
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to know the protocol in use when the broker logs a message
> like:
> {noformat}
> WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure
> to 127.0.0.1:48558 has been detected: null [code=GENERIC_EXCEPTION]{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] [Resolved] (ARTEMIS-4922) Spurious warn message when OpenWire client disconnects
[
https://issues.apache.org/jira/browse/ARTEMIS-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4922.
--
Fix Version/s: 2.36.0
Resolution: Fixed
> Spurious warn message when OpenWire client disconnects
> --
>
> Key: ARTEMIS-4922
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4922
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Oftentimes when an OpenWire client disconnects normally the broker will log a
> message like:
> {noformat}
> WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure
> to /127.0.0.1:48558 has been detected: null [code=GENERIC_EXCEPTION]{noformat}
> This behavior was introduced via ARTEMIS-4483.
--
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-4919) AMQP protocol level errors not handled cleanly
Timothy A. Bish created ARTEMIS-4919: Summary: AMQP protocol level errors not handled cleanly Key: ARTEMIS-4919 URL: https://issues.apache.org/jira/browse/ARTEMIS-4919 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.35.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 When a remote client violates some AMQP protocol level requirements the proton AMQP transport can throw and this is not handled correctly an the transport error event is also not handled which leads to issues if you try and handle the exception from the transport by triggering a transport level error event. Not handling these errors can cause missed transport flushes and or missed cleanup of connection level resources in some cases. -- 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-4884) [OpenWire] WireFormatNegotiator timeout during multiple parallel SSL connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864720#comment-17864720
]
Timothy A. Bish commented on ARTEMIS-4884:
--
I have run your ActiveMQ Classic client test on a Ubuntu host with an option of
1,000 connections in the configuration file and it completes without issue or
errors.
> [OpenWire] WireFormatNegotiator timeout during multiple parallel SSL
> connections
>
>
> Key: ARTEMIS-4884
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4884
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.35.0
>Reporter: Liviu Citu
>Assignee: Justin Bertram
>Priority: Major
> Attachments: activemq-clients.zip, broker.xml, classic-client_1.log,
> classic-client_2.log
>
>
> We are currently in process of migrating our broker from Classic 5.x to
> Artemis. We are currently using CMS C++ client for connecting to the broker
> {*}but the issue replicates also with the OpenWire JMS client{*}. Everything
> works fine when using non-SSL setup (on both Windows and Linux) but we have
> some issues when using SSL on Linux (SSL on Windows is OK).
> The initial problem started with the following exceptions on the client side:
> {noformat}
> 024-02-22 09:54:37.377 [ERROR] [activemq_connection.cc:336] CMS exception:
> Channel was inactive for too long:
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371
> FILE: activemq/core/ActiveMQConnection.cpp, LINE:
> 573{noformat}
> while on the broker side we had:
> {noformat}
> 2024-03-20 12:29:08,700 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224088: Timeout (10 seconds) on acceptor "netty-ssl-acceptor" during
> protocol handshake with /10.21.70.53:33053 has occurred.{noformat}
> To bypass these we have added the following setting to the *broker.xml*
> *netty-ssl-acceptor* acceptor: *handshake-timeout=0*
> However now the exceptions we are receiving are:
> *+CMS client+*
> {noformat}
> 2024-05-22 09:26:40.842 [ERROR] [activemq_connection.cc:348] CMS exception:
> OpenWireFormatNegotiator::onewayWire format negotiation timeout: peer did not
> send his wire format.
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371
> FILE: activemq/core/ActiveMQConnection.cpp, LINE: 573{noformat}
> +*Java client*+
> {noformat}
> jakarta.jms.JMSException: Could not connect to broker URL:
> ssl://linux_host:61617?keepAlive=true&wireFormat.maxInactivityDuration=0.
> Reason: java.net.SocketException: Broken pipe
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:423)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:353)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> .
> Caused by: java.net.SocketException: Broken pipe
> at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:425)
> ~[?:?]
> at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:445) ~[?:?]
> at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:831) ~[?:?]
> at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1035)
> ~[?:?]
> at
> java.base/sun.security.ssl.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:345)
> ~[?:?]
> at
> java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1308)
> ~[?:?]
> at
> org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at java.base/java.io.DataOutputStream.flush(DataOutputStream.java:128)
> ~[?:?]
> at
> org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:336)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:318)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
> at
> org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:181)
> ~[activemq-client-6.1.2.jar!/:6.1.2]
[jira] [Commented] (ARTEMIS-4916) Allow for server-side option to always pre-acknowledge
[ https://issues.apache.org/jira/browse/ARTEMIS-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864709#comment-17864709 ] Timothy A. Bish commented on ARTEMIS-4916: -- That would require work to implement for no real savings as the client is going to be sending acks back than then still need handled even if it was to toss them out. > Allow for server-side option to always pre-acknowledge > -- > > Key: ARTEMIS-4916 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4916 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Josh Byster >Priority: Minor > > Pre-acknowledge is a great feature to have, but is unsupported if using > ActiveMQ classic clients. It would be nice to be able to enable this directly > on the server such that all sessions are created with pre-ack true as an > alternative option. -- 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-4873) Add an AMQP federation example showing pull mode
[ https://issues.apache.org/jira/browse/ARTEMIS-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4873. -- Resolution: Fixed > Add an AMQP federation example showing pull mode > > > Key: ARTEMIS-4873 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4873 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > > Add a new AMQP Federation example showing the federation policy configured to > pull messages only when there is no local pending messages on the Queue. -- 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-4873) Add an AMQP federation example showing pull mode
Timothy A. Bish created ARTEMIS-4873: Summary: Add an AMQP federation example showing pull mode Key: ARTEMIS-4873 URL: https://issues.apache.org/jira/browse/ARTEMIS-4873 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.35.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 Add a new AMQP Federation example showing the federation policy configured to pull messages only when there is no local pending messages on the Queue. -- 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-4842) Update protonj2 to v1.0.0-M20
[ https://issues.apache.org/jira/browse/ARTEMIS-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4842. -- Resolution: Fixed > Update protonj2 to v1.0.0-M20 > - > > Key: ARTEMIS-4842 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4842 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: 2.36.0 > > > Update protonj2 to latest to pickup some test peer API updates -- 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-4842) Update protonj2 to v1.0.0-M20
Timothy A. Bish created ARTEMIS-4842: Summary: Update protonj2 to v1.0.0-M20 Key: ARTEMIS-4842 URL: https://issues.apache.org/jira/browse/ARTEMIS-4842 Project: ActiveMQ Artemis Issue Type: Task Components: Tests Affects Versions: 2.35.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 Update protonj2 to latest to pickup some test peer API updates -- 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-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4814.
--
Resolution: Fixed
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4814:
-
Fix Version/s: 2.36.0
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4814:
-
Affects Version/s: 2.35.0
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4820) AMQP TTL message property being treated as int instead of uint
[ https://issues.apache.org/jira/browse/ARTEMIS-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4820. -- Resolution: Fixed > AMQP TTL message property being treated as int instead of uint > -- > > Key: ARTEMIS-4820 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4820 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When setting message expiration from AMQP header TTL the value should be > treated as an unsigned integer but is instead being read as a signed integer. > -- 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-4820) AMQP TTL message property being treated as int instead of uint
Timothy A. Bish created ARTEMIS-4820: Summary: AMQP TTL message property being treated as int instead of uint Key: ARTEMIS-4820 URL: https://issues.apache.org/jira/browse/ARTEMIS-4820 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.35.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 When setting message expiration from AMQP header TTL the value should be treated as an unsigned integer but is instead being read as a signed integer. -- 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-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
[ https://issues.apache.org/jira/browse/ARTEMIS-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4817. -- Resolution: Fixed > AMQP Federation address policy doesn't allow credit configuration to override > parent settings > - > > Key: ARTEMIS-4817 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4817 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0, 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.36.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When processing address matches the federation address policy manager doesn't > check against the address policy for a receiver credits value but instead > looks at the parent level settings which means if the global value is set to > zero and the address policy has an override this is missed and it won't > federate an address. -- 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-4817) AMQP Federation address policy doesn't allow credit configuration to override parent settings
Timothy A. Bish created ARTEMIS-4817: Summary: AMQP Federation address policy doesn't allow credit configuration to override parent settings Key: ARTEMIS-4817 URL: https://issues.apache.org/jira/browse/ARTEMIS-4817 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.35.0, 2.34.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.36.0 When processing address matches the federation address policy manager doesn't check against the address policy for a receiver credits value but instead looks at the parent level settings which means if the global value is set to zero and the address policy has an override this is missed and it won't federate an address. -- 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] (AMQ-9513) AMQP 1.0 message with multiple Data sections can be sent to broker but corrupted
[ https://issues.apache.org/jira/browse/AMQ-9513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853200#comment-17853200 ] Timothy A. Bish commented on AMQ-9513: -- Just a note of clarification here, proton-j is perfectly capable of handling messages with multiple Data sections in them, only the simple Message wrapper object provided by proton-j for basic message use cases does not handle that case. You would need to refactor the classic code to not use that and instead handle messages in such a way as to allow those multiple Data sections to pass through or be converted if going from AMQP to Openwire message types. > AMQP 1.0 message with multiple Data sections can be sent to broker but > corrupted > > > Key: AMQ-9513 > URL: https://issues.apache.org/jira/browse/AMQ-9513 > Project: ActiveMQ Classic > Issue Type: Bug > Components: AMQP >Affects Versions: 5.18.4, 6.1.2 >Reporter: Yuriy Lepikhov >Priority: Major > > ActiveMQ Classic uses Qpid Proton-J to support AMQP 1.0, but Qpid Proton-J > does not support messages with multiple Data sections (see, PROTON-2299). > One can send such message to broker, broker will accept such message, but it > will use last odd Data section as message body (no exception thrown or > warning logged). > It is even possible to receive such message from broker, but it will contain > fewer bytes than original (and may be not from beginning). > -- 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-4801) AMQP Session address query cache can have invalid state for long lived sessions
[ https://issues.apache.org/jira/browse/ARTEMIS-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4801. -- Resolution: Fixed > AMQP Session address query cache can have invalid state for long lived > sessions > --- > > Key: ARTEMIS-4801 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4801 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The AMQPSessionCallback retains a map of AddressQueryResult instances for > previous address checks. This map is not updated if the state of broker > addresses changes, neither addresses added, removed or updated states are > reflected in the cache. This leads to issues for long running sessions where > a link attach may fail for a non-existent address and on a later attempt > should succeed if the address was added but can't because the cache will > still hold the non-exists query result. Other scenarios are possible such as > an address removed and re-added with different routing type but the former > case is more serious. > The cache should be removed and if a similar optimization is actually found > to be needed a better mechanism should be chosen to avoid the issues found. -- 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-4801) AMQP Session address query cache can have invalid state for long lived sessions
Timothy A. Bish created ARTEMIS-4801: Summary: AMQP Session address query cache can have invalid state for long lived sessions Key: ARTEMIS-4801 URL: https://issues.apache.org/jira/browse/ARTEMIS-4801 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.34.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.35.0 The AMQPSessionCallback retains a map of AddressQueryResult instances for previous address checks. This map is not updated if the state of broker addresses changes, neither addresses added, removed or updated states are reflected in the cache. This leads to issues for long running sessions where a link attach may fail for a non-existent address and on a later attempt should succeed if the address was added but can't because the cache will still hold the non-exists query result. Other scenarios are possible such as an address removed and re-added with different routing type but the former case is more serious. The cache should be removed and if a similar optimization is actually found to be needed a better mechanism should be chosen to avoid the issues found. -- 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-4799) Broker Connection Receiver attach handled incorrectly
Timothy A. Bish created ARTEMIS-4799: Summary: Broker Connection Receiver attach handled incorrectly Key: ARTEMIS-4799 URL: https://issues.apache.org/jira/browse/ARTEMIS-4799 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.34.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.35.0 The AMQP Broker Connection Receiver configuration creates a receiver for messages from a remote AMQP source however the attach handling is not properly handled leading to a receiver that thinks it is operating as an opened anonymous relay sender meaning it only routes messages with a set 'To' field in the properties. The receiver attach should be using the locally defined target as the address for incoming messages and ignore an 'To' value in the message properties. -- 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-4792) Add support for setting consumer priority on AMQP Receiver Source addresses
[
https://issues.apache.org/jira/browse/ARTEMIS-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4792:
-
Summary: Add support for setting consumer priority on AMQP Receiver Source
addresses (was: Add support for setting consumer priority on AMQP Source
address)
> Add support for setting consumer priority on AMQP Receiver Source addresses
> ---
>
> Key: ARTEMIS-4792
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4792
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: AMQP
>Affects Versions: 2.34.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.35.0
>
>
> When creating a receiver link from a client the only way currently to adjust
> the consumer priority on the broker is to set a value in the receiver
> properties to indicate the desired priority. For some client AMQP client
> libraries this is not simple or not possible in the provided API. To solve
> this we can add support for parsing URI type options from the source address
> of the receiver attach and look for the option "consumer-priority" which is
> also used by the Core client to configure consumer priority (Openwire clients
> can do the same via an openwire client property "consumer.priority").
> This updates the client receiver attach to extract properties from the
> address the source which have the form:
> {code:java}
> address?consumer-priority=1{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] [Created] (ARTEMIS-4792) Add support for setting consumer priority on AMQP Source address
Timothy A. Bish created ARTEMIS-4792:
Summary: Add support for setting consumer priority on AMQP Source
address
Key: ARTEMIS-4792
URL: https://issues.apache.org/jira/browse/ARTEMIS-4792
Project: ActiveMQ Artemis
Issue Type: New Feature
Components: AMQP
Affects Versions: 2.34.0
Reporter: Timothy A. Bish
Assignee: Timothy A. Bish
Fix For: 2.35.0
When creating a receiver link from a client the only way currently to adjust
the consumer priority on the broker is to set a value in the receiver
properties to indicate the desired priority. For some client AMQP client
libraries this is not simple or not possible in the provided API. To solve
this we can add support for parsing URI type options from the source address of
the receiver attach and look for the option "consumer-priority" which is also
used by the Core client to configure consumer priority (Openwire clients can do
the same via an openwire client property "consumer.priority").
This updates the client receiver attach to extract properties from the address
the source which have the form:
{code:java}
address?consumer-priority=1{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-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4788. -- Fix Version/s: 2.35.0 Resolution: Fixed > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.35.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- 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-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4788: - Affects Version/s: 2.34.0 > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- 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-4788) AMQP Federation Broker connection can deadlock broker shutdown
Timothy A. Bish created ARTEMIS-4788: Summary: AMQP Federation Broker connection can deadlock broker shutdown Key: ARTEMIS-4788 URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.33.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish In a rare race between broker shutdown and create of federation consumer the broker connection federation manager can deadlock and hang the shutdown of the broker. -- 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-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848315#comment-17848315
]
Timothy A. Bish edited comment on ARTEMIS-4777 at 5/21/24 6:06 PM:
---
The broker connection senders and receivers operate on matching Queues as not
so clearly described in the documentation, and not on a simple address match as
you are trying to configure. In your case when configuring the receiver it
won't attach to the remote unless a queue is created under the matched address
'test' which means you need a local consumer on the address to trigger the
receiver being created on the remote.
I'd guess that the intended use case for broker connection address senders and
receivers was mainly around actual queues and not for multicast addresses,
although as mentioned above you can make it happen with a consumer attached.
For multicast it doesn't make a ton of sense to bring across messages if
there's no place for them to go once they arrive which is why this was mainly
geared towards queues.
There is a call out for this behavior in the documentation after the XML
configuration examples
bq. Receivers can only be matched to a local queue that already exists.
Therefore, if receivers are being used, ensure that queues are pre-created
locally. Otherwise, the broker cannot match the remote queues and addresses.
was (Author: tabish121):
The broker connection senders and receivers operate on matching Queues as not
so clearly described in the documentation, and not on a simple address match as
you are trying to configure. In your case when configuring the receiver it
won't attach to the remote unless a queue is created under the matched address
'test' which means you need a local consumer on the address to trigger the
receiver being created on the remote.
I'd guess that the intended use case for broker connection address senders and
receivers was mainly around actual queues and not for multicast addresses,
although as mentioned above you can make it happen with a consumer attached.
For multicast it doesn't make a ton of sense to bring across messages if
there's no place for them to go once they arrive which is why this was mainly
geared towards queues.
There is a call out for this behavior in the documentation after the XML
configuration examples
{noformat}
Receivers can only be matched to a local queue that already exists. Therefore,
if receivers are being used, ensure that queues are pre-created locally.
Otherwise, the broker cannot match the remote queues and addresses.
{noformat}
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848315#comment-17848315
]
Timothy A. Bish edited comment on ARTEMIS-4777 at 5/21/24 6:05 PM:
---
The broker connection senders and receivers operate on matching Queues as not
so clearly described in the documentation, and not on a simple address match as
you are trying to configure. In your case when configuring the receiver it
won't attach to the remote unless a queue is created under the matched address
'test' which means you need a local consumer on the address to trigger the
receiver being created on the remote.
I'd guess that the intended use case for broker connection address senders and
receivers was mainly around actual queues and not for multicast addresses,
although as mentioned above you can make it happen with a consumer attached.
For multicast it doesn't make a ton of sense to bring across messages if
there's no place for them to go once they arrive which is why this was mainly
geared towards queues.
There is a call out for this behavior in the documentation after the XML
configuration examples
{noformat}
Receivers can only be matched to a local queue that already exists. Therefore,
if receivers are being used, ensure that queues are pre-created locally.
Otherwise, the broker cannot match the remote queues and addresses.
{noformat}
was (Author: tabish121):
The broker connection senders and receivers operate on matching Queues as not
so clearly described in the documentation, and not on a simple address match as
you are trying to configure. In your case when configuring the receiver it
won't attach to the remote unless a queue is created under the matched address
'test' which means you need a local consumer on the address to trigger the
receiver being created on the remote.
I'd guess that the intended use case for broker connection address senders and
receivers was mainly around actual queues and not for multicast addresses,
although as mentioned above you can make it happen with a consumer attached.
For multicast it doesn't make a ton of sense to bring across messages if
there's no place for them to go once they arrive which is why this was mainly
geared towards queues.
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4777) Broker connections (AMQP) with receiver operation not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848315#comment-17848315
]
Timothy A. Bish commented on ARTEMIS-4777:
--
The broker connection senders and receivers operate on matching Queues as not
so clearly described in the documentation, and not on a simple address match as
you are trying to configure. In your case when configuring the receiver it
won't attach to the remote unless a queue is created under the matched address
'test' which means you need a local consumer on the address to trigger the
receiver being created on the remote.
I'd guess that the intended use case for broker connection address senders and
receivers was mainly around actual queues and not for multicast addresses,
although as mentioned above you can make it happen with a consumer attached.
For multicast it doesn't make a ton of sense to bring across messages if
there's no place for them to go once they arrive which is why this was mainly
geared towards queues.
> Broker connections (AMQP) with receiver operation not working
> -
>
> Key: ARTEMIS-4777
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4777
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.33.0
> Environment: Server installed on CentOS Linux release 7.9.2009
>Reporter: Piero Cena
>Priority: Major
>
> Trying to connect an Artemis instance to an instance of ActiveMQ Classic 5.15
> in order to receive messages from one destination (preferably a topic
> destination). Here is the configuration on Artemis instance:
> {code:xml}
>
> retry-interval="1000" reconnect-attempts="2" user="xxx{*}" password="xxx{*}">
>
>
> {code}
> The address "test" is predefined as multicast on Artemis and exists on the
> other side:
> {code:xml}
>
>
> {code}
> On startup Artemis will connect correctly to Classic but no message is
> received on the Artemis side when published to the Classic destination "test".
> The same test has done with two Artemis brokers, one configured as above, but
> the results are the same.
> Only "sender" or "mirror" operations seem to work properly (between 2
> Artemis).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-1152) Investigate suspected Double-Checked Locking
[
https://issues.apache.org/jira/browse/ARTEMIS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-1152.
Resolution: Not A Problem
Patterns appear to use correct volatile and locking state, reopen if further
evidence is available
> Investigate suspected Double-Checked Locking
>
>
> Key: ARTEMIS-1152
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1152
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.1.0
>Reporter: Jiri Daněk
>Priority: Minor
> Attachments: ActiveMQThreadPoolExecutor.java.png,
> ManagementServiceImpl.java.png
>
>
> Coverity found instance of Double-Checked Locking. According to the resources
> at the end, the variable has to either be declared volatile, or
> double-checked locking should not be used, or the variable has to be atomic
> (int, float, ...). Otherwise, in a general case this may lead to threads
> accessing partially initialized objects.
> There is 9 Coverity finds in the category "Data race undermines locking", the
> following one looks to me as clear examples of the Double-Checked Locking
> pattern
> h4. ActiveMQJMSContext.java
> {noformat}
> 130 private void checkSession() {
> 1. thread1_checks_field: Thread1 uses the value read from field session
> in the condition session == null. It sees that the condition is true.
>
> CID 1409080 (#2-1 of 2): Check of thread-shared field evades lock acquisition
> (LOCK_EVASION)
> 5. thread2_checks_field_early: Thread2 checks session, reading it after
> Thread1 assigns to session but before some of the correlated field
> assignments can occur. It sees the condition session == null as being false.
> It continues on before the critical section has completed, and can read data
> changed by that critical section while it is in an inconsistent state.
> Remove this outer, unlocked check of session.
> 131 if (session == null) {
> 2. thread1_acquires_lock: Thread1 acquires lock ActiveMQJMSContext.this.
> 132 synchronized (this) {
> 133if (closed)
> 134 throw new IllegalStateRuntimeException("Context is closed");
> 3. thread1_double_checks_field: Thread1 double checks the field session
> in the condition session == null.
> 135if (session == null) {
> 136 try {
> 137 if (xa) {
> 138 session = ((XAConnection)
> connection).createXASession();
> 139 } else {
> 4. thread1_modifies_field: Thread1 modifies the field session. This
> modification can be re-ordered with other correlated field assignments within
> this critical section at runtime. Thus, checking the value of session is not
> an adequate test that the critical section has completed unless the guarding
> lock is held while checking. If session is assigned a newly constructed
> value, note that the JVM is allowed to reorder the assignment of the new
> reference to session before any field assignments that may occur in the
> constructor. Control is switched to Thread2.
> 140 session = connection.createSession(sessionMode);
> 141 }
> 142 } catch (JMSException e) {
> 143 throw JmsExceptionUtils.convertToRuntimeException(e);
> 144 }
> 145}
> 146 }
> 147 }
> 148 }
> {noformat}
> In addition to that, the demo version of HP Fortify tool reports the
> following two additional instances (as well as the previous one already
> reported by Coverity).
> h4. ActiveMQThreadPoolExecutor.java
> !ActiveMQThreadPoolExecutor.java.png!
> h4. ManagementServiceImpl.java
> !ManagementServiceImpl.java.png!
> I came to believe that this warning from the tool is real, at least the first
> instance, and that it should be investigated more closely by somebody more
> experienced.
> #. http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> #.
> https://www.securecoding.cert.org/confluence/display/java/LCK10-J.+Use+a+correct+form+of+the+double-checked+locking+idiom
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
Timothy A. Bish created ARTEMIS-4745: Summary: Allow configuration of AMQP federation pull consumer batch size Key: ARTEMIS-4745 URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.33.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.34.0 When Queue federation receiver links are configured to only pull messages from the remote when local capacity allows it they grant a fixed credit window amount of link credits currently. In some cases control over this batch size value is beneficial. We can add an additional configuration property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4744) AMQP broker connections don't fully support multi host URIs
Timothy A. Bish created ARTEMIS-4744: Summary: AMQP broker connections don't fully support multi host URIs Key: ARTEMIS-4744 URL: https://issues.apache.org/jira/browse/ARTEMIS-4744 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.33.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.34.0 When configuring a multi host connection URI for an AMQP broker connection the connection will utilize some but not all of the configuration. The broker will attempt connection to each host and port part specific on the URI but does not apply configuration specific to a given host. This can lead to failure on connect due to using the TLS configuration from the first host when attempting to connect to the following N hosts. Users need to be able to configure TLS specific options per host as values such as host verification, SNI and trust stores can vary amongst hosts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2682) OpenWireMessageConverter refactoring
[
https://issues.apache.org/jira/browse/ARTEMIS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-2682.
Resolution: Abandoned
> OpenWireMessageConverter refactoring
>
>
> Key: ARTEMIS-2682
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2682
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: OpenWire
>Affects Versions: 2.12.0
>Reporter: Federico Valeri
>Priority: Minor
> Labels: openwire, refactoring
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> I'm proposing the {{OpenWireMessageConverter}} refactoring to have a similar
> layout as the {{AMQPConverter}}. The latter has two dedicated classes for
> inbound and outbound messages with a singleton entry point for the converter.
> This change is basically doing the same without semantics change and also
> adding a unit test for the converter. I'm also eliminating some duplicated
> code, but the bulk of the code remains untouched.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-1383) Improved Priority queue
[ https://issues.apache.org/jira/browse/ARTEMIS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-1383. Resolution: Abandoned > Improved Priority queue > --- > > Key: ARTEMIS-1383 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1383 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > The original PriorityLinkedList implementation is based on a double linked > list implementation that suffer of: > * fragmentation along the heap > * pointer chasing due to the presence of nodes > * allocation heavy (ie each add operation forces allocation of nodes) > * high hidden (ie the nodes) memory footprint that lead to wrong memory > estimations > It is possible to provide a specialized chunked implementation that can > address all these issues while providing a better performance (throughput, > latency and memory footprint wise). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4047) Artemis does not send message to consumer AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836352#comment-17836352
]
Timothy A. Bish commented on ARTEMIS-4047:
--
This seems like a candidate for closure given the comment from [~jbertram]
There are no known issues with consumer blockages in the AMQP bits that we are
currently aware of.
> Artemis does not send message to consumer AMQP
> --
>
> Key: ARTEMIS-4047
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4047
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.25.0, 2.26.0
>Reporter: daves
>Priority: Major
> Attachments: 1.PNG, 2.PNG, 3.PNG, 4.PNG, 5.PNG, All.zip
>
>
> The broker does not send messages from one of many existing queues to the
> connected consumer.
> According to the UI the queue does contain ~15k messages.
> I’m not able to consume any of these messages. I also tried to read a message
> using the browse function of the UI/console but that does not work eighter.
> The message was created by a AMQP client and should be consumed by another
> AMQP client.
> I tried to capture the situation in a few screenshots…
> I don’t know which data can help you to understand the situation, so I’ve
> collected everything:
> * Logs
> * Broker
> * Data
> Please let me know if there are any other data I should add to the ticket.
> I don’t think that the code of my client is relevant since the problem only
> exist for a single queue…but here it is anyway:
> {code:java}
> using Amqp;
> using Amqp.Framing;
> using Amqp.Types;
> namespace Test;
> public sealed class MessageConsumer
> {
> private readonly String _address;
> private readonly CancellationToken _cancellationToken;
> private readonly String _consumerName;
> private readonly String[] _destinations;
> public MessageConsumer( String address, String consumerName, String[]
> destinations, CancellationToken cancellationToken )
> {
> _address = address;
> _consumerName = consumerName;
> _destinations = destinations;
> _cancellationToken = cancellationToken;
> }
> public async Task StartReceivingMessages()
> {
> await Task.Yield();
> while ( !_cancellationToken.IsCancellationRequested )
> {
> var connectionFactory = new ConnectionFactory();
> var address = new Address( _address );
> try
> {
> var connection = await connectionFactory.CreateAsync( address
> );
> var session = ( (IConnection) connection ).CreateSession();
> var receivers = new List();
> foreach ( var destination in _destinations )
> {
> var receiver = session.CreateReceiver(
> $"{_consumerName}_{destination}",
> new Source
> {
> Address =
> destination,
> Capabilities =
> new[] { new Symbol( "queue" ) }
> } );
> receivers.Add( receiver );
> }
> while ( !_cancellationToken.IsCancellationRequested )
> foreach ( var receiver in receivers )
> {
> // ReceiveAsync( TimeSpan.Zero ); blocks forever and
> no messages will be received
> var message = await receiver.ReceiveAsync(
> TimeSpan.FromMilliseconds( 1 ) );
> if ( message == null )
> continue;
> receiver.Accept( message );
> Console.WriteLine( $"{_consumerName} - Received
> message with id: '{message.Properties.MessageId}'" );
> }
> }
> catch ( Exception ex )
> {
> Console.WriteLine( $"{_consumerName} - Connection error in
> producer '{_consumerName}' {ex.Message} => create new connection." );
> await Task.Delay( 1000, CancellationToken.None );
> }
> }
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3359) Auto-Create of non-durable queue not possible
[
https://issues.apache.org/jira/browse/ARTEMIS-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-3359.
Resolution: Information Provided
> Auto-Create of non-durable queue not possible
> -
>
> Key: ARTEMIS-3359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3359
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Rene Koch
>Priority: Major
>
> I have a application in which I want to have 1 durable and 1 non-durable
> queue in Active MQ Artemis. For connecting to this message bus I use
> amqpnetlite (https://github.com/Azure/amqpnetlite)
>
> {code:java}
> var source = new Source()
> {
> };
> if (durable)
> {
> source.Address =
> amqpAddressConverter.GetSubscriberAddress(address, useLoadBalancing);
> source.Durable = 1;
> source.ExpiryPolicy = new Symbol("never");
> source.DistributionMode = new Symbol("copy");
> }
> else
> {
> source.Address =
> amqpAddressConverter.GetSubscriberAddress(address);
> source.Durable = 0;
> }
> var receiverLink = new ReceiverLink(session, linkName, source, null);
> {code}
> {{}}
> So this is my receiver link. As shown I set the Durable uint of the Source
> which will given into the ReceiverLink.
> Because as I saw in the Active MQ Artemis documentation, that the Durable is
> a boolean but within the amqpnetlite library it is an uint my understanding
> is that everything over 0 should be true and 0 should be false. (Seen here:
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-terminus-durability)]
> At first the behaviour was very strange: Even when the Aretemis Web interface
> was shown a queue as durable it would be deleted as soon as no consumer would
> be connected.
> I found this:
>
> [https://stackoverflow.com/questions/66360625/activemq-artemis-queue-deleted-after-shutdown-of-consuming-client]
> which describes that even durable queues get deleted because of the default
> behaviour.
> So I changed the broker.xml and set AUTO-DELETE-QUEUE to false.
> Since then the behaviour completly switched:
> Both (durable = 1 and durable = 0) queues are being still there after the
> connection disconnected.
> What I saw, either the configuration in the broker.xml - every queue will be
> durable = true, it doesn't mather what I set within the Link.
> So how to create a durable and a non-durable connection correctly?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3359) Auto-Create of non-durable queue not possible
[
https://issues.apache.org/jira/browse/ARTEMIS-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836343#comment-17836343
]
Timothy A. Bish commented on ARTEMIS-3359:
--
TerminusDurability is not the same thing as queue durability and so is not used
internally for indicating this, the client can you the dynamic node option to
create a temporary queue attached to the subscription that will be destroyed
when the client disconnects.
The TerminusDurabily is only used in one place, appropriately, to indicate the
subscription to a topic node is durable or not. That is, the link/terminus is
durable or not. Not the queue the broker happens to create (which is an
implementation detail, there need not be any queue) in terms of the AMQP
specification.
> Auto-Create of non-durable queue not possible
> -
>
> Key: ARTEMIS-3359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3359
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Rene Koch
>Priority: Major
>
> I have a application in which I want to have 1 durable and 1 non-durable
> queue in Active MQ Artemis. For connecting to this message bus I use
> amqpnetlite (https://github.com/Azure/amqpnetlite)
>
> {code:java}
> var source = new Source()
> {
> };
> if (durable)
> {
> source.Address =
> amqpAddressConverter.GetSubscriberAddress(address, useLoadBalancing);
> source.Durable = 1;
> source.ExpiryPolicy = new Symbol("never");
> source.DistributionMode = new Symbol("copy");
> }
> else
> {
> source.Address =
> amqpAddressConverter.GetSubscriberAddress(address);
> source.Durable = 0;
> }
> var receiverLink = new ReceiverLink(session, linkName, source, null);
> {code}
> {{}}
> So this is my receiver link. As shown I set the Durable uint of the Source
> which will given into the ReceiverLink.
> Because as I saw in the Active MQ Artemis documentation, that the Durable is
> a boolean but within the amqpnetlite library it is an uint my understanding
> is that everything over 0 should be true and 0 should be false. (Seen here:
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-terminus-durability)]
> At first the behaviour was very strange: Even when the Aretemis Web interface
> was shown a queue as durable it would be deleted as soon as no consumer would
> be connected.
> I found this:
>
> [https://stackoverflow.com/questions/66360625/activemq-artemis-queue-deleted-after-shutdown-of-consuming-client]
> which describes that even durable queues get deleted because of the default
> behaviour.
> So I changed the broker.xml and set AUTO-DELETE-QUEUE to false.
> Since then the behaviour completly switched:
> Both (durable = 1 and durable = 0) queues are being still there after the
> connection disconnected.
> What I saw, either the configuration in the broker.xml - every queue will be
> durable = true, it doesn't mather what I set within the Link.
> So how to create a durable and a non-durable connection correctly?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2481) Outdated johnzon-core Library Upgrade to 1.1.13
[ https://issues.apache.org/jira/browse/ARTEMIS-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2481. Resolution: Fixed Johnzon has already been updated beyond this, most recently to v1.2.21 in ARTEMIS-4364 > Outdated johnzon-core Library Upgrade to 1.1.13 > --- > > Key: ARTEMIS-2481 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2481 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.5.0 >Reporter: Roger Soland >Priority: Minor > > The org.apache.johnzon-core Library the artemis-core-client is built on > should be upgraded to the latest version 1.1.13. > artemis-core-client depends on johnzon-core 0.9.0 which is really outdated > and buggy. We have been struggling with the bug > https://issues.apache.org/jira/browse/JOHNZON-158. a state issue of the > JsonStreamParser Implementation. > By using the Artemis Resource Adapter, the johnzon-core Library is > automatically on our application classpath and brings in the buggy JsonParser. > Also the newest ActiveMQ Artemis Version 2.10.0 is affected > -- This message was sent by Atlassian Jira (v8.20.10#820010)
