[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=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=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=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=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=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)
[jira] [Closed] (ARTEMIS-1472) Individualize Loggers to Debug Protocol issues.
[ https://issues.apache.org/jira/browse/ARTEMIS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-1472. Resolution: Abandoned Given this has lingered for many years and we've gotten along without any additional changes I'm closing this one. > Individualize Loggers to Debug Protocol issues. > --- > > Key: ARTEMIS-1472 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1472 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.3.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > > AMQP developers will usually set PN_TRACE_FRM as a System.property to get out > some information from Proton regarding the frame processing. > It would be a nice idea to also throw some log.info when that property is set > at Artemis.. around AMQP Processing, making it easier to Debug AMQP packets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2605) Unable to create non-durable queue with specific name
[ https://issues.apache.org/jira/browse/ARTEMIS-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2605. Resolution: Not A Problem As discussed in the issue AMQP clients setting terminus durability has no affect on Queue durability as that is not what that field does and AMQP itself has no behavioral linkage to Topics or Queues. > Unable to create non-durable queue with specific name > - > > Key: ARTEMIS-2605 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2605 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.2 >Reporter: Dirkjan >Priority: Major > > When attaching as a receiver to create a new queue, it appears Artemis will > try to create a durable queue by default, even if I specify that the queue > should not be durable. If my user does not have permission to create durable > queues (even though it has permission to create non-durable queues), creation > of the queue will fail with a permission error. > More context: > The application I'm targeting usually uses Core messages to do RPC, but it > accepts AMQP messages as well, so it could be that there is a mismatch here > between how things are set up. > > When using Core, I see that ServerSessionPacketHandler triggers on a packet > with type -12 to create the queue with a well-defined name, which in the end > dispatches to ServerSessionImpl.createQueue() with temporary = true and > durable = false. This is the behavior I'm seeking to replicate. However, all > my attempts to create to a temporary non-durable queue by attaching to it > with AMQP seem to be failing so far. > > With my AMQP client, I try to create the response queue by attaching to it > with source address = . This lets me end up in > ProtonServerSenderContext.initialise() by way of > AMQPSessionContext.addSender(). However, this throws a permission error > (AMQ119213, my user does not have permission for CREATE_DURABLE_QUEUE). This > is surprising to me because I leave the "durable" field as default, which > should mean to default to no durability. It seems to happen because > AMQPSessionCallback.queueQuery() calls (through some indirection) > ServerSessionImpl.createQueue() with durable = true. > > I could potentially create non-durable queues by setting dynamic = true, but > in that case Artemis will create the queue with random UUID name, whereas my > user only has permission to create queues with a name with a specific prefix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-1899) AMQPMessage.getIntProperty() throws "UnsignedInteger cannot be cast to java.lang.Integer"
[
https://issues.apache.org/jira/browse/ARTEMIS-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-1899.
Resolution: Not A Problem
The methods are doing just what they say they do in their names, getting
Integer or Long values, not UnsignedInteger or UnsignedLong values, that can be
done via getObjectProperty as the issue already points out. The other option
is to go to the proton message itself and get the application properties
directly.
> AMQPMessage.getIntProperty() throws "UnsignedInteger cannot be cast to
> java.lang.Integer"
> -
>
> Key: ARTEMIS-1899
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1899
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0
>Reporter: Johan Stenberg
>Priority: Minor
>
> While testing a custom Artemis plugin with a RHEA based AMQP client I
> encountered the following exception in the server:
> {noformat}
> 23:56:57.993 WARN [y-threads)] ?(:)
> org.apache.qpid.proton.amqp.UnsignedInteger cannot be cast to
> java.lang.Integer
> java.lang.ClassCastException: org.apache.qpid.proton.amqp.UnsignedInteger
> cannot be cast to java.lang.Integer
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.getIntProperty(AMQPMessage.java:987)
> ~[artemis-amqp-protocol-2.6.0.jar:?]
> {noformat}
> On the client I am setting a message property with an int value and try to
> access this int value in the custom plugin on the server via
> AMQPMessage.getIntProperty.
> The problem lies in the fact that the AMQPMessage.getIntProperty method
> simply tries to cast the property to Integer and does not perform the same
> conversion as done by
> [getObjectProperty|https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L1030].
> Same is true for AMQPMessage.getLongProperty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2614) Create queues for AMQP clients based on FQQN
[ https://issues.apache.org/jira/browse/ARTEMIS-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2614. Resolution: Won't Fix Based on the discussion in the linked Github pull request it was decided that this is not something that should be added and so I am closing this issue > Create queues for AMQP clients based on FQQN > > > Key: ARTEMIS-2614 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2614 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Reporter: Krzysztof Porębski >Priority: Major > Time Spent: 11h 40m > Remaining Estimate: 0h > > As a follow up to the discussion on the mailing list I would like to suggest > a new feature regarding FQQN implementation for AMQP protocol - creating > queues. > Currently there is no way of attaching to a queue using FQQN if the queue is > not configured upfront. It should be changed so it would be possible to > create queue via FQQN and a subset of the following capabilities: > - shared > - topic > - queue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2113) When AMQP links are opened and closed in quick succession, Artemis doesn’t always respond with attach/detach frames confirming the opening/closing of the links
[
https://issues.apache.org/jira/browse/ARTEMIS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-2113.
Resolution: Information Provided
This is a limitation of the proton-j protocol engine that cannot process
pipelined Open, Begin, Attach and Detach framings due to the temporal squashing
being done. The broker has not part at that level and can't intervene. A
workaround is to await the initial attach response before sending the detach to
ensure the broker has a chance to process the data without pipelining.
> When AMQP links are opened and closed in quick succession, Artemis doesn’t
> always respond with attach/detach frames confirming the opening/closing of
> the links
> ---
>
> Key: ARTEMIS-2113
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2113
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.3
> Environment: This test was done in .NET using the Amqp.Net Lite
> library 2.1.4 (which is the latest version).
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: ArtemisTest.zip, artemis-2.6.3.log, artemis-2.7.0.log,
> dotnet-artemis-2.6.3.txt, dotnet-artemis-2.7.0.txt
>
>
> A trace of a message exchange with Artemis where this has occurred is below.
> The lines highlighted in yellow show opening and then closing two AMQP links,
> but Artemis doesn’t respond after that with its own attach/detach frames,
> which acknowledge the opening/closing of those links. The lines highlighted
> in green are heartbeat frames sent to Artemis, sent every 15 seconds, which
> illustrates that one minute passed without receiving the attach/detach frames
> from Artemis.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-43a6c9ad,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#14892c}SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty{color}
> Note that this doesn’t always happen. Sometimes Artemis does respond, as
> shown by the lines highlighted in bold/grey in the trace below.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-b00e0be7,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> *{color:#707070}RECV (ch=0)
> attach(name:link1,handle:0,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:q1)){color}*
> RECV (ch=0)
>
[jira] [Closed] (ARTEMIS-4307) AMQP Artemis "hangs" on single message delivery
[
https://issues.apache.org/jira/browse/ARTEMIS-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-4307.
Resolution: Cannot Reproduce
This has likely been addressed by changes in ARTEMIS-4233 amongst other fixes
since 2.28.0 and I would recommend updating to the latest release. A
reproducer would helpful if the problem still manifests with the latest release
> AMQP Artemis "hangs" on single message delivery
> ---
>
> Key: ARTEMIS-4307
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4307
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.28.0
>Reporter: daves
>Priority: Major
>
> My Setup:
> - Multiple clients ~500 send messages to a queue in Artemis using AMQP
> - A single application reads consumes the messages from the queue using AMQP
> At some point - I sadly don't know how to reproduce it - my consuming client
> does not receive messages anymore.
> From the perspective of my client the call to receiving new messages
> (AMQP.NET lite) just hands/waits for messages and never returns. Also, It
> still looks like the connection is open and healthy.
> On the Artemis side I see two different pictures.
> - In the Broker console I can see a consumer from my client, and it tells me
> that 1 Messages is in Transit. ...as if Artemis is waiting for an ACK for the
> message.
> In the Artemis log is see this:
> {noformat}
> 2023-06-09 15:11:37,934 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> Array must not be empty or null
> java.lang.IllegalArgumentException: Array must not be empty or null
> at
> org.apache.qpid.proton.codec.CompositeReadableBuffer.append(CompositeReadableBuffer.java:691)
> ~[proton-j-0.34.0.jar:?]
> at
> org.apache.qpid.proton.engine.impl.DeliveryImpl.send(DeliveryImpl.java:345)
> ~[proton-j-0.34.0.jar:?]
> at org.apache.qpid.proton.engine.impl.SenderImpl.send(SenderImpl.java:74)
> ~[proton-j-0.34.0.jar:?]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext$LargeMessageDeliveryContext.deliverInitialPacket(ProtonServerSenderContext.java:715)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext$LargeMessageDeliveryContext.deliver(ProtonServerSenderContext.java:622)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.deliverLarge(ProtonServerSenderContext.java:837)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:567)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.core.paging.cursor.PagedReferenceImpl.run(PagedReferenceImpl.java:116)
> ~[artemis-server-2.28.0.jar:2.28.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[artemis-commons-2.28.0.jar:?]
> 2023-06-09 15:11:37,934 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=3, filter=null, binding=LocalQueueBinding
> [address=MyQName, queue=QueueImpl[name=MyQName, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=MyApp], temp=false]@776d381a, filter=null,
> name=MyQName, clusterName=MyQName431ed7e1-05dd-11ee-ade9-f44d30e2ecf9]],
> message=PagedReferenceImpl [message=PagedMessageImpl [queueIDs=[47],
> transactionID=-1, page=25, message=AMQPLargeMessage( [durable=false,
> messageID=12940183, address=MyQName, size=0, scanningStatus=SCANNED,
> applicationProperties={atmid=CHE8128,
> content-type=application/x-protobuf, content-version=2.0,
>
[jira] [Closed] (ARTEMIS-2059) NettyWritable should use UTF-8 exact length to encode strings
[ https://issues.apache.org/jira/browse/ARTEMIS-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-2059. Resolution: Not A Problem Closing this as the discussion seems to have concluded there was no broker side issue here and no further work as been done here. > NettyWritable should use UTF-8 exact length to encode strings > - > > Key: ARTEMIS-2059 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2059 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > NettyWritable.put(String) tries to enlarge the buffer used to write a UTF-8 > string until ByteBufUtil.utf8MaxBytes. > That means that it will fail or will enlarge any ByteBuf that is perfectly > sized to contain the encoded string. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-889) dispositions sent after link is detached with close=false and no error are ignored
[ https://issues.apache.org/jira/browse/ARTEMIS-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836202#comment-17836202 ] Timothy A. Bish commented on ARTEMIS-889: - It's quite likely it behaves exactly as it did before as the proton-j bits haven't really changed since then > dispositions sent after link is detached with close=false and no error are > ignored > -- > > Key: ARTEMIS-889 > URL: https://issues.apache.org/jira/browse/ARTEMIS-889 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 1.5.1 >Reporter: Gordon Sim >Priority: Major > > See > https://issues.apache.org/jira/browse/DISPATCH-595?focusedCommentId=15745826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15745826 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4720) Add additional example for AMQP federation showing TLS configuration
Timothy A. Bish created ARTEMIS-4720: Summary: Add additional example for AMQP federation showing TLS configuration Key: ARTEMIS-4720 URL: https://issues.apache.org/jira/browse/ARTEMIS-4720 Project: ActiveMQ Artemis Issue Type: Task Components: ActiveMQ-Artemis-Examples, AMQP Affects Versions: 2.33.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.34.0 Add a new example in the AMQP Federation examples showing how to configure the broker connections to use TLS to connect to the remote. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-209) [AMQP] Broker sends frames after SASL failure
[
https://issues.apache.org/jira/browse/ARTEMIS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835785#comment-17835785
]
Timothy A. Bish commented on ARTEMIS-209:
-
About the same place as before, proton-j still does this but I don't see it
being changed. There is protonj2 now but there is no effort to replace the
existing protocol head so the issue continues to exist in the broker as before.
> [AMQP] Broker sends frames after SASL failure
> -
>
> Key: ARTEMIS-209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-209
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: AMQP
>Affects Versions: 1.0.0
> Environment: SASL negotiation over AMQP
>Reporter: Charles E. Rolke
>Assignee: Timothy A. Bish
>Priority: Major
>
> The client sends bogus credentials to the Artemis server. The server
> correctly fails with sasl.outcome code: auth(1). So far so good. Then the
> server sends an AMQP protocol negotiation frame as if everything was OK.
> After failing SASL the server should close the connection.
> Trace file:
> https://people.apache.org/~chug/artemis/20150821-1/artemis-sasl-fail-but-sends-amqp-header.html
> From the trace:
> {noformat}
> 10.10.1.1:1340 -> 10.10.10.254:5672 -> init SASL (3): (1.0.0)
> 10.10.1.1:1340 -> 10.10.10.254:5672 -> method sasl.init
> 10.10.1.1:1340 <- 10.10.10.254:5672 <-init SASL (3): (1.0.0), method
> sasl.mechanisms, method sasl.outcome
> 10.10.1.1:1340 <- 10.10.10.254:5672 <-init AMQP (0): (1.0.0)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4666. -- Resolution: Fixed > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.34.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4666: - Fix Version/s: 2.34.0 > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.34.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834374#comment-17834374 ] Timothy A. Bish commented on ARTEMIS-4666: -- I took some time to track this down and it comes down to a bug in the XML parsing that is not correctly configuring the Queue match policy and when an Openwire client connects there are false positive matches on the advisory destinations that come into existence which can't be auto created on the remote and the federation connection breaks. You could work around the issue by setting the address match in your configuration to a specific Queue name you want to federate instead of a wildcard. > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Assignee: Timothy A. Bish >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish reassigned ARTEMIS-4666: Assignee: Timothy A. Bish > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Assignee: Timothy A. Bish >Priority: Major > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3262) Cannot get max-hops >= 2 federation to work
[
https://issues.apache.org/jira/browse/ARTEMIS-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-3262.
--
Resolution: Information Provided
> Cannot get max-hops >= 2 federation to work
> ---
>
> Key: ARTEMIS-3262
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3262
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Federation
>Affects Versions: 2.17.0, 2.20.0
> Environment: Artemis 2.17.0 on 3 Linux machines
> Dragonwell OpenJDK 11.0.10
>Reporter: Zhang Xiang
>Priority: Major
> Labels: ActiveMQ, federation
>
> I want to construct a 3-level MQTT message forwarding system:
> A → B → C
> Once a message publish under the topic "from-A" to A, all clients subscribing
> "from-A" on B and C should receive that message.
> Here is the config of B:
>
> {code:xml}
>
> tcp://192.168.1.200:61616
>
>
>
>
> true
>
> connector-A
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> And here is the config of C:
>
>
> {code:xml}
>
> tcp://192.168.1.100:61616
>
>
>
>
>
> connector-C
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is that even I've set max-hops to 2, the message cannot be
> forwarded for more than 1 time.
>
> * If I published a "from-A" message to B, all clients subscribing "from-A"
> on C could receive the message.
> * If I published a "from-A" message to A, all clients subscribing "from-A"
> on B could receive the message, but clients on C wouldn't!
> The example config files provided by the software packages do not cover this
> kind of situations, nor do the documentation.
> Please tell me if it is a bug and if not, what should I do.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3262) Cannot get max-hops >= 2 federation to work
[
https://issues.apache.org/jira/browse/ARTEMIS-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831977#comment-17831977
]
Timothy A. Bish commented on ARTEMIS-3262:
--
This is a configuration issue, the max-hops value isn't actually needed in this
scenario as there is no loop of federated brokers that could cause cycling. If
you wanted to add max hops to this setup you should set the value to two on
both brokers or set as the message is getting stopped right now from moving to
C from B when published on A is because the configuration on C says only one
hop is allowed and the message already hopped once from A to B.
> Cannot get max-hops >= 2 federation to work
> ---
>
> Key: ARTEMIS-3262
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3262
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Federation
>Affects Versions: 2.17.0, 2.20.0
> Environment: Artemis 2.17.0 on 3 Linux machines
> Dragonwell OpenJDK 11.0.10
>Reporter: Zhang Xiang
>Priority: Major
> Labels: ActiveMQ, federation
>
> I want to construct a 3-level MQTT message forwarding system:
> A → B → C
> Once a message publish under the topic "from-A" to A, all clients subscribing
> "from-A" on B and C should receive that message.
> Here is the config of B:
>
> {code:xml}
>
> tcp://192.168.1.200:61616
>
>
>
>
> true
>
> connector-A
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> And here is the config of C:
>
>
> {code:xml}
>
> tcp://192.168.1.100:61616
>
>
>
>
>
> connector-C
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is that even I've set max-hops to 2, the message cannot be
> forwarded for more than 1 time.
>
> * If I published a "from-A" message to B, all clients subscribing "from-A"
> on C could receive the message.
> * If I published a "from-A" message to A, all clients subscribing "from-A"
> on B could receive the message, but clients on C wouldn't!
> The example config files provided by the software packages do not cover this
> kind of situations, nor do the documentation.
> Please tell me if it is a bug and if not, what should I do.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4703) Add additional Queue federation example for AMQP federation
[ https://issues.apache.org/jira/browse/ARTEMIS-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4703: - Affects Version/s: 2.33.0 (was: 2.34.0) > Add additional Queue federation example for AMQP federation > --- > > Key: ARTEMIS-4703 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4703 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: 2.33.0 > > > Add an additional Queue federation example showing how to federate queue > messages through an intermediary broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4703) Add additional Queue federation example for AMQP federation
[ https://issues.apache.org/jira/browse/ARTEMIS-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4703: - Fix Version/s: 2.34.0 (was: 2.33.0) > Add additional Queue federation example for AMQP federation > --- > > Key: ARTEMIS-4703 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4703 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: 2.34.0 > > > Add an additional Queue federation example showing how to federate queue > messages through an intermediary broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4703) Add additional Queue federation example for AMQP federation
Timothy A. Bish created ARTEMIS-4703: Summary: Add additional Queue federation example for AMQP federation Key: ARTEMIS-4703 URL: https://issues.apache.org/jira/browse/ARTEMIS-4703 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.34.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 Add an additional Queue federation example showing how to federate queue messages through an intermediary broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4660) BAD_COPY_PASTE in VersionedStompFrameHandler.java
[
https://issues.apache.org/jira/browse/ARTEMIS-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-4660.
Resolution: Duplicate
> BAD_COPY_PASTE in VersionedStompFrameHandler.java
> -
>
> Key: ARTEMIS-4660
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4660
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.32.0
>Reporter: Andrey Slepykh
>Assignee: Clebert Suconic
>Priority: Minor
> Labels: easyfix, pull-request-available
>
> PR:
> [https://github.com/apache/activemq-artemis/pull/4835/commits/b893c6c4d35b42ee2364144c8850bd104caf6fe7]
> In 1st branch (line 274) of the {{if()}} statement, the
> {{Boolean.parseBoolean()}} method accepts the value
> {{{}frame.getHeader(Stomp.Headers.Subscribe.NO_LOCAL){}}}, which is used in
> line 273.
> In 2nd branch (line 276), the {{Boolean.parseBoolean()}} method accepts the
> value {{{}frame.getHeader(Stomp.Headers.Subscribe.NO_LOCAL){}}}, although the
> other value {{frame.hasHeader(Stomp.Headers.Subscribe.ACTIVEMQ_NO_LOCAL)}} is
> used.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author A. Slepykh.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4661) DLS_DEAD_LOCAL_STORE in AMQPLargeMessage.java
[ https://issues.apache.org/jira/browse/ARTEMIS-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-4661. Resolution: Duplicate > DLS_DEAD_LOCAL_STORE in AMQPLargeMessage.java > - > > Key: ARTEMIS-4661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4661 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native >Affects Versions: 2.32.0 >Reporter: Andrey Slepykh >Assignee: Clebert Suconic >Priority: Minor > Labels: easy-fix, pull-request-available > > PR: > [https://github.com/apache/activemq-artemis/pull/4835/commits/dafef6784743b1ecdf085a19e65efb41224d26c4] > The local variable constructorPos is initialized with the value of > buffer.position() in line 330, but the variable itself is not used anywhere > else, which may indicate an error. > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Slepykh. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4662) BAD_COPY_PASTE in ActiveMQScheduledLeaseLock.java
[ https://issues.apache.org/jira/browse/ARTEMIS-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-4662. Resolution: Duplicate > BAD_COPY_PASTE in ActiveMQScheduledLeaseLock.java > - > > Key: ARTEMIS-4662 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4662 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native >Affects Versions: 2.32.0 >Reporter: Andrey Slepykh >Assignee: Clebert Suconic >Priority: Minor > Labels: easy-fix, pull-request-available > > PR: > [https://github.com/apache/activemq-artemis/pull/4835/commits/b893c6c4d35b42ee2364144c8850bd104caf6fe7] > In the detectAndReportRenewSlowness() method, the logger.error() and > logger.warn() methods are called 3 times. > In two of the three calls, the method arguments correspond to parameters that > are tested in the if() conditional construct. > Also, the arguments of the logger.error() and logger.warn() methods are > identical in lines 139 and 141, respectively, which may indicate that they > were copied incorrectly. > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Slepykh. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4683) Add additional examples for AMQP federation
Timothy A. Bish created ARTEMIS-4683: Summary: Add additional examples for AMQP federation Key: ARTEMIS-4683 URL: https://issues.apache.org/jira/browse/ARTEMIS-4683 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 Add additional examples to the features examples demonstrating various configurations for AMQP federation so setup common typologies or use cases such as multicast fanout or queue federation priority settings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823693#comment-17823693 ] Timothy A. Bish commented on ARTEMIS-4666: -- Likely then there is some interplay in core federation and openwire clients that is not accounted for. I would suggest having a look at the new AMQP federation over [AMQP broker connections|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html#federation] although you might need to wait for the next release for the latest round of fixes there as well. The other option is to create an integration test that demonstrates the issue to try and help getting someone to look into it. > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Priority: Major > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823348#comment-17823348 ] Timothy A. Bish commented on ARTEMIS-4666: -- Looks like you only defined the Queue on server 1 and not on server 2, I'd define it on both. > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Priority: Major > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4666) Federated queue consumers do not receive messages on classic clients
[ https://issues.apache.org/jira/browse/ARTEMIS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823315#comment-17823315 ] Timothy A. Bish commented on ARTEMIS-4666: -- I don't think the broker test suite does any checks for Openwire specifically when using the Core federation bits. Looking at the test sample you have supplied in Github I notice that you do not statically define the Queues in the broker configuration and I know from looking at the federation code that it is not always going to cope with that as one might think. I'd recommend trying your tests after having defined the address and queues your sample is going to use and see if that allows it to pass. > Federated queue consumers do not receive messages on classic clients > > > Key: ARTEMIS-4666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4666 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Federation >Affects Versions: 2.32.0 >Reporter: Josh Byster >Priority: Major > > Federated queues with A upstream and downstream to B do not seem to work as > expected when the client JMS implementation is ActiveMQ Classic v5.16.2 (used > in my example, but also verified the issue is present with v5.18.3 and > v6.0.1). With Artemis JMS as the client, it seems to work as expected. > When running a producer on A and a consumer on B with the classic > org.apache.activemq.ActiveMQConnectionFactory, the consumer on B does not > consume any messages that the producer sends. When B is restarted, it then > consumes the messages. > This works properly with ActiveMQ Artemis > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory. I've > created a minimal reproducible example > [here|https://github.com/josh-byster/artemis-classic-consumer-bug/tree/master]. > Running server1 and server2 and then first starting up the Consumer then > running the Producer class, we can see that no messages are logged in console > by the consumer. When you restart the consumer, the messages are consumed. > This is an issue whether you attach a MessageListener or you call receive() > directly. If you switch the ActiveMQConnectionFactory implementation to > Artemis, it works as expected. > I don't think this necessarily warrants a fix if it's an issue specifically > with the classic client, since the solution is just to upgrade clients to > Artemis. However, if it is something that can be patched on the server, that > would be great. I do, however, think it would be good to note this down in > the docs that it's not supported with classic clients, since I spent a while > debugging it. However, most other features do work as expected with the > clients running the classic version, which is much appreciated as it makes > migration significantly easier. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4665. -- Resolution: Fixed > Fix intermittent failures in a few AMQP federation tests > > > Key: ARTEMIS-4665 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Add some additional state checks in the server to server test for AMQP > federation ensure an address send isn't discarded before the remote receiver > has attached which is causing some intermittent test failures, also add some > other state checks to ensure test prerequisites are in place. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4665: - Description: Add some additional state checks in the server to server test for AMQP federation ensure an address send isn't discarded before the remote receiver has attached which is causing some intermittent test failures, also add some other state checks to ensure test prerequisites are in place. (was: Add some additional state checks in the server to server test for AMQP federation ensure an address send isn't discard before the remote receiver has attached which is causing some intermittent test failures) > Fix intermittent failures in a few AMQP federation tests > > > Key: ARTEMIS-4665 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add some additional state checks in the server to server test for AMQP > federation ensure an address send isn't discarded before the remote receiver > has attached which is causing some intermittent test failures, also add some > other state checks to ensure test prerequisites are in place. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4665: - Summary: Fix intermittent failures in a few AMQP federation tests (was: Fix intermittent failures in a few AMQP federation address tests) > Fix intermittent failures in a few AMQP federation tests > > > Key: ARTEMIS-4665 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add some additional state checks in the server to server test for AMQP > federation ensure an address send isn't discard before the remote receiver > has attached which is causing some intermittent test failures -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish reopened ARTEMIS-4665: -- > Fix intermittent failures in a few AMQP federation address tests > > > Key: ARTEMIS-4665 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add some additional state checks in the server to server test for AMQP > federation ensure an address send isn't discard before the remote receiver > has attached which is causing some intermittent test failures -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4665. -- Resolution: Fixed > Fix intermittent failures in a few AMQP federation address tests > > > Key: ARTEMIS-4665 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add some additional state checks in the server to server test for AMQP > federation ensure an address send isn't discard before the remote receiver > has attached which is causing some intermittent test failures -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests
Timothy A. Bish created ARTEMIS-4665: Summary: Fix intermittent failures in a few AMQP federation address tests Key: ARTEMIS-4665 URL: https://issues.apache.org/jira/browse/ARTEMIS-4665 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 Add some additional state checks in the server to server test for AMQP federation ensure an address send isn't discard before the remote receiver has attached which is causing some intermittent test failures -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4658) AMQP Federation should prevent reflection of multicast messages between nodes
Timothy A. Bish created ARTEMIS-4658: Summary: AMQP Federation should prevent reflection of multicast messages between nodes Key: ARTEMIS-4658 URL: https://issues.apache.org/jira/browse/ARTEMIS-4658 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 When using a topology where brokers are dual federating messages for addresses the federation producers and consumers should prevent reflection between the two nodes. This allows for more complex configuration where the max hops value is insufficient to prevent duplicates and cases of infinite reflection if the user forgets to configure max hops. Such a case would be a hub and spoke type setup where the producers and consumers are on each of the spokes and the hub is the way point, here the max hops needs to be set to '2' but this allows for a reflection from the hub back to the sending spoke. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4645) Update AMQP broker connection tests to use better connector names
[ https://issues.apache.org/jira/browse/ARTEMIS-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4645. -- Resolution: Fixed > Update AMQP broker connection tests to use better connector names > - > > Key: ARTEMIS-4645 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4645 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Update various AMQP broker connection tests to use more unique names for > broker connections and policies to provide more details in logs of the > various tests that make them identifiable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4653) AMQP Federation should apply queue consumer filters for demand
Timothy A. Bish created ARTEMIS-4653: Summary: AMQP Federation should apply queue consumer filters for demand Key: ARTEMIS-4653 URL: https://issues.apache.org/jira/browse/ARTEMIS-4653 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 For Queue federation the federation consumers should apply a consumer defined filter over the Queue defined filter to avoid pulling message across the link that won't be deliverable. Add options for disabling this and also disabling per consumer consumer priority tracking to allow for reduction of federation links when desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4645) Update AMQP broker connection tests to use better connector names
Timothy A. Bish created ARTEMIS-4645: Summary: Update AMQP broker connection tests to use better connector names Key: ARTEMIS-4645 URL: https://issues.apache.org/jira/browse/ARTEMIS-4645 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 Update various AMQP broker connection tests to use more unique names for broker connections and policies to provide more details in logs of the various tests that make them identifiable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4642) AMQP Federation demand tracking can under count demand in some narrow cases
Timothy A. Bish created ARTEMIS-4642: Summary: AMQP Federation demand tracking can under count demand in some narrow cases Key: ARTEMIS-4642 URL: https://issues.apache.org/jira/browse/ARTEMIS-4642 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 In some narrow cases the AMQP federation demand tracking can under count the demand on an address or queue and should track more closely the current demand regardless of a federation link being active. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4641) Allow AMQP federation to recover from missing or removed resources
Timothy A. Bish created ARTEMIS-4641: Summary: Allow AMQP federation to recover from missing or removed resources Key: ARTEMIS-4641 URL: https://issues.apache.org/jira/browse/ARTEMIS-4641 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 When an AMQP federation instance attempts to federate an address or queue it can fail if the remote address or queue is not present or cannot be created based on broker policy. A federation link can also closed if the federated resource is removed from the remote broker by management etc. In those cases the remote broker should note the resources that were targets of federation and send alerts to the source federation broker to notify it that these resources become available for federation and the source should attempt again to create federation links if demand still exists. This allows an AMQP federation instance to heal itself based on updates from the remote. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4626) AMQP Federation demand tracking can overcount demand
[ https://issues.apache.org/jira/browse/ARTEMIS-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4626. -- Resolution: Fixed > AMQP Federation demand tracking can overcount demand > > > Key: ARTEMIS-4626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4626 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.33.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The demand tracking for Address bindings and Queue consumers that controls > when a federation consumer is created and destroyed can race on start of > federation with consumers or bindings being added and removed and over count > the demand leading to the federation consumers not being shutdown when demand > on the local broker drops to zero. A better mechanism of tracking needs to > be added to make demand tracking idempotent for additions and removals of > local demand and the startup demand checks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4626) AMQP Federation demand tracking can overcount demand
Timothy A. Bish created ARTEMIS-4626: Summary: AMQP Federation demand tracking can overcount demand Key: ARTEMIS-4626 URL: https://issues.apache.org/jira/browse/ARTEMIS-4626 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 The demand tracking for Address bindings and Queue consumers that controls when a federation consumer is created and destroyed can race on start of federation with consumers or bindings being added and removed and over count the demand leading to the federation consumers not being shutdown when demand on the local broker drops to zero. A better mechanism of tracking needs to be added to make demand tracking idempotent for additions and removals of local demand and the startup demand checks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4575) Don't start all previous consumers when new consumer added
[
https://issues.apache.org/jira/browse/ARTEMIS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish resolved ARTEMIS-4575.
--
Fix Version/s: 2.32.0
Assignee: Timothy A. Bish
Resolution: Fixed
> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.32.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal
> cost of adding a new consumer increases due to a linear-time iteration
> through all the existing consumers with OpenWire. It becomes very slow to add
> a new consumer when there are already 100k+ on a session, for example. We
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
> {code}
> {{Most of the time is spent in this method, starting consumers that have
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
> consumer.setStarted(s);
>}
>started = s;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4575) Don't start all previous consumers when new consumer added
[
https://issues.apache.org/jira/browse/ARTEMIS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4575:
-
Affects Version/s: 2.31.2
> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal
> cost of adding a new consumer increases due to a linear-time iteration
> through all the existing consumers with OpenWire. It becomes very slow to add
> a new consumer when there are already 100k+ on a session, for example. We
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
> {code}
> {{Most of the time is spent in this method, starting consumers that have
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
> consumer.setStarted(s);
>}
>started = s;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4568) Support reloading AMQP broker federation configuration
[ https://issues.apache.org/jira/browse/ARTEMIS-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4568. -- Resolution: Fixed > Support reloading AMQP broker federation configuration > -- > > Key: ARTEMIS-4568 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4568 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP, Configuration >Affects Versions: 2.31.2 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.32.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add support for reload of AMQP federation broker connection configuration > from XML and broker properties such that active federations are stopped and > updated with new configuration settings, and support add and remove of AMQP > federation broker connections. > This change will explicitly not reload broker connections that contain Mirror > configuration as that is not supported and could lead to breakages of > mirroring. Mirrors can be added if not present before but once added they > cannot be removed without a broker stop and restart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4568) Support reloading AMQP broker federation configuration
[ https://issues.apache.org/jira/browse/ARTEMIS-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4568: - Description: Add support for reload of AMQP federation broker connection configuration from XML and broker properties such that active federations are stopped and updated with new configuration settings, and support add and remove of AMQP federation broker connections. This change will explicitly not reload broker connections that contain Mirror configuration as that is not supported and could lead to breakages of mirroring. Mirrors can be added if not present before but once added they cannot be removed without a broker stop and restart. was:Add support for reload of AMQP federation broker connection configuration from XML and broker properties such that active federations are stopped and updated with new configuration settings, and support add and remove of AMQP federation broker connections. > Support reloading AMQP broker federation configuration > -- > > Key: ARTEMIS-4568 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4568 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP, Configuration >Affects Versions: 2.31.2 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.32.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add support for reload of AMQP federation broker connection configuration > from XML and broker properties such that active federations are stopped and > updated with new configuration settings, and support add and remove of AMQP > federation broker connections. > This change will explicitly not reload broker connections that contain Mirror > configuration as that is not supported and could lead to breakages of > mirroring. Mirrors can be added if not present before but once added they > cannot be removed without a broker stop and restart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4568) Support reloading AMQP broker federation configuration
Timothy A. Bish created ARTEMIS-4568: Summary: Support reloading AMQP broker federation configuration Key: ARTEMIS-4568 URL: https://issues.apache.org/jira/browse/ARTEMIS-4568 Project: ActiveMQ Artemis Issue Type: New Feature Components: AMQP, Configuration Affects Versions: 2.31.2 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.32.0 Add support for reload of AMQP federation broker connection configuration from XML and broker properties such that active federations are stopped and updated with new configuration settings, and support add and remove of AMQP federation broker connections. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794373#comment-17794373 ] Timothy A. Bish commented on OPENWIRE-71: - The comparison doesn't really hold up though between a project that carries a protocol level codec and the implementation of the command (and Message) objects that are used in the server vs a spec jar that carries only an API with no implementation. Just use semantic versioning and leave yourself room to grow when things go sideways, which they always do. > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-71) Align OpenWire project major version to protocol major version (12.0.0)
[ https://issues.apache.org/jira/browse/OPENWIRE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794327#comment-17794327 ] Timothy A. Bish commented on OPENWIRE-71: - That doesn't make a ton of sense to me and in general typing release number to some ephemeral notion of what they imply generally leads to trouble. Sort of reminds me of projects that tried to tie the version of the JDK that a given release used to its version. Just used standard versioning so that the project can grow and change as needed and simply document what versions of Openwire are supported inside a given release. > Align OpenWire project major version to protocol major version (12.0.0) > --- > > Key: OPENWIRE-71 > URL: https://issues.apache.org/jira/browse/OPENWIRE-71 > Project: ActiveMQ OpenWire > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > > OpenWire v12 should be served by activemq-openwire-12.0.0.jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated OPENWIRE-69: Description: PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should be fixed, and maybe checked by the annotation processor since no two properties should have the same sequence. (was: PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should fixed, and maybe checked by the annotation processor since no two properties should have the same sequence.) > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
Timothy A. Bish created OPENWIRE-69: --- Summary: Sequence ID for openwire properties is not correct in some types Key: OPENWIRE-69 URL: https://issues.apache.org/jira/browse/OPENWIRE-69 Project: ActiveMQ OpenWire Issue Type: Bug Reporter: Timothy A. Bish Assignee: Christopher L. Shannon PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should fixed, and maybe checked by the annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4502) Allow core messages to cross AMQP broker connection links without conversion
[ https://issues.apache.org/jira/browse/ARTEMIS-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4502: - Summary: Allow core messages to cross AMQP broker connection links without conversion (was: Allow core message to cross AMQP broker connection links without conversion) > Allow core messages to cross AMQP broker connection links without conversion > > > Key: ARTEMIS-4502 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4502 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Affects Versions: 2.31.2 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.32.0 > > > Currently when message cross AMQP broker connection links used for mirroring > or federation they must be converted from Core to AMQP and then eventually > back if sent to a core consumer. This is worse for large messages as they > must be fully loaded into memory before converting to AMQP. > For AMQP Federation and broker mirroring we should use special encoding and > decoding to convey the core and core large messages across the wire without > conversion to avoid the overhead and caveats of that conversion. This > requires some not insignificant refactoring and use of custom message format > values to signal when an AMQP delivery is a core message so that the protocol > head can recreate the core message from the sent data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4502) Allow core message to cross AMQP broker connection links without conversion
Timothy A. Bish created ARTEMIS-4502: Summary: Allow core message to cross AMQP broker connection links without conversion Key: ARTEMIS-4502 URL: https://issues.apache.org/jira/browse/ARTEMIS-4502 Project: ActiveMQ Artemis Issue Type: New Feature Components: AMQP Affects Versions: 2.31.2 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.32.0 Currently when message cross AMQP broker connection links used for mirroring or federation they must be converted from Core to AMQP and then eventually back if sent to a core consumer. This is worse for large messages as they must be fully loaded into memory before converting to AMQP. For AMQP Federation and broker mirroring we should use special encoding and decoding to convey the core and core large messages across the wire without conversion to avoid the overhead and caveats of that conversion. This requires some not insignificant refactoring and use of custom message format values to signal when an AMQP delivery is a core message so that the protocol head can recreate the core message from the sent data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4470) Headers loss in message sent from AMQP producer to AMQP consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779919#comment-17779919 ] Timothy A. Bish commented on ARTEMIS-4470: -- In general the broker APIs are not documented or not documented well, mostly you will need to take it upon yourself to figure out the implementation. The Message APIs should probably be updated to clarify that after all mutation operations are complete (regardless of which protocol underlies the message) a re-encode should be done to ensure the transmission is accurate. This API documentation should though be protocol agnostic however. You are welcome to open a PR for review. > Headers loss in message sent from AMQP producer to AMQP consumer > > > Key: ARTEMIS-4470 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4470 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.31.0 >Reporter: Mohanavalli A >Priority: Major > > Hi Team, > Our message flow involves a AMQP Producer, Broker (with custom plugin) and a > AMQP Consumer. > The message is sent by Producer to TEST queue with few headers, the broker > plugin adds few more headers on BeforeSend event on the TEST queue. When the > message is consumed by the consumer from TEST we see loss of certain headers. > > We started facing this after the recent migration of the consumer from > Openwire to AMQP protocol. There is no loss of header when the > Producer/Consumer is on openwire. > > Scenario1 > -- > Producer(AMQP) to TEST > Header1:String, Header2:long > > Plugin on BeforeSend event on TEST > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) from TEST > Headers : Header1,Header2 (PluginHeader1, PluginHeader2 missing) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > > Scenario2 > -- > Producer(AMQP) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(Openwire) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > Scenario3 > -- > Producer(Openwire) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > all headers are present TEST1 queue. > > Thanks, > Mohanavalli A -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4470) Headers loss in message sent from AMQP producer to AMQP consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779546#comment-17779546 ] Timothy A. Bish commented on ARTEMIS-4470: -- It's going to depend on what you change in the Message, in AMQP the standard properties, application-properties, and application-data (the body) are considered immutable, but you have decided in a plugin you will violate that and mutate them, therefore the message must be re-encoded as internally those bits are treated as a binary blob that would be sent unchanged as they are by spec immutable. So this is not a drawback of AMQP is a consequence of your choice to mutate the immutable message portion en route. http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#toc > Headers loss in message sent from AMQP producer to AMQP consumer > > > Key: ARTEMIS-4470 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4470 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.31.0 >Reporter: Mohanavalli A >Priority: Major > > Hi Team, > Our message flow involves a AMQP Producer, Broker (with custom plugin) and a > AMQP Consumer. > The message is sent by Producer to TEST queue with few headers, the broker > plugin adds few more headers on BeforeSend event on the TEST queue. When the > message is consumed by the consumer from TEST we see loss of certain headers. > > We started facing this after the recent migration of the consumer from > Openwire to AMQP protocol. There is no loss of header when the > Producer/Consumer is on openwire. > > Scenario1 > -- > Producer(AMQP) to TEST > Header1:String, Header2:long > > Plugin on BeforeSend event on TEST > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) from TEST > Headers : Header1,Header2 (PluginHeader1, PluginHeader2 missing) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > > Scenario2 > -- > Producer(AMQP) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(Openwire) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > Scenario3 > -- > Producer(Openwire) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > all headers are present TEST1 queue. > > Thanks, > Mohanavalli A -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4470) Headers loss in message sent from AMQP producer to AMQP consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-4470. Resolution: Information Provided > Headers loss in message sent from AMQP producer to AMQP consumer > > > Key: ARTEMIS-4470 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4470 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.31.0 >Reporter: Mohanavalli A >Priority: Major > > Hi Team, > Our message flow involves a AMQP Producer, Broker (with custom plugin) and a > AMQP Consumer. > The message is sent by Producer to TEST queue with few headers, the broker > plugin adds few more headers on BeforeSend event on the TEST queue. When the > message is consumed by the consumer from TEST we see loss of certain headers. > > We started facing this after the recent migration of the consumer from > Openwire to AMQP protocol. There is no loss of header when the > Producer/Consumer is on openwire. > > Scenario1 > -- > Producer(AMQP) to TEST > Header1:String, Header2:long > > Plugin on BeforeSend event on TEST > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) from TEST > Headers : Header1,Header2 (PluginHeader1, PluginHeader2 missing) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > > Scenario2 > -- > Producer(AMQP) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(Openwire) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > Scenario3 > -- > Producer(Openwire) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > all headers are present TEST1 queue. > > Thanks, > Mohanavalli A -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4470) Headers loss in message sent from AMQP producer to AMQP consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779505#comment-17779505 ] Timothy A. Bish commented on ARTEMIS-4470: -- The method re-encodes the payload based on any changes and would not make sense to do on each add of a property as you would create a massive performance impact and increase GC overhead encoding and re-encoding with each property add or remove. > Headers loss in message sent from AMQP producer to AMQP consumer > > > Key: ARTEMIS-4470 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4470 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.31.0 >Reporter: Mohanavalli A >Priority: Major > > Hi Team, > Our message flow involves a AMQP Producer, Broker (with custom plugin) and a > AMQP Consumer. > The message is sent by Producer to TEST queue with few headers, the broker > plugin adds few more headers on BeforeSend event on the TEST queue. When the > message is consumed by the consumer from TEST we see loss of certain headers. > > We started facing this after the recent migration of the consumer from > Openwire to AMQP protocol. There is no loss of header when the > Producer/Consumer is on openwire. > > Scenario1 > -- > Producer(AMQP) to TEST > Header1:String, Header2:long > > Plugin on BeforeSend event on TEST > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) from TEST > Headers : Header1,Header2 (PluginHeader1, PluginHeader2 missing) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > > Scenario2 > -- > Producer(AMQP) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(Openwire) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue. > > Scenario3 > -- > Producer(Openwire) > Header1:String, Header2:long > > Plugin > Adds two new headers PluginHeader1(String), PluginHeader2(long) > > Consumer(AMQP) > Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are > present) > > Additional info: > If browsing message in console on TEST: Headers : > Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present) > If the message is moved from TEST to TEST1 queue directly on the Web Console, > all headers are present TEST1 queue. > > Thanks, > Mohanavalli A -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4470) Headers loss in message sent from AMQP producer to AMQP consumer
[
https://issues.apache.org/jira/browse/ARTEMIS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779135#comment-17779135
]
Timothy A. Bish commented on ARTEMIS-4470:
--
Would need to see a reproducer to diagnose this fully but it sounds like your
plugin is modifying the AMQP message and not calling:
{code:java}
message.reencode();{code}
Without this the underlying encoded data will not be updated and the original
buffers will be sent when the received message is routed to a consumer.
> Headers loss in message sent from AMQP producer to AMQP consumer
>
>
> Key: ARTEMIS-4470
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4470
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.31.0
>Reporter: Mohanavalli A
>Priority: Major
>
> Hi Team,
> Our message flow involves a AMQP Producer, Broker (with custom plugin) and a
> AMQP Consumer.
> The message is sent by Producer to TEST queue with few headers, the broker
> plugin adds few more headers on BeforeSend event on the TEST queue. When the
> message is consumed by the consumer from TEST we see loss of certain headers.
>
> We started facing this after the recent migration of the consumer from
> Openwire to AMQP protocol. There is no loss of header when the
> Producer/Consumer is on openwire.
>
> Scenario1
> --
> Producer(AMQP) to TEST
> Header1:String, Header2:long
>
> Plugin on BeforeSend event on TEST
> Adds two new headers PluginHeader1(String), PluginHeader2(long)
>
> Consumer(AMQP) from TEST
> Headers : Header1,Header2 (PluginHeader1, PluginHeader2 missing)
>
> Additional info:
> If browsing message in console on TEST: Headers :
> Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present)
> If the message is moved from TEST to TEST1 queue directly on the Web Console,
> the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue.
>
>
> Scenario2
> --
> Producer(AMQP)
> Header1:String, Header2:long
>
> Plugin
> Adds two new headers PluginHeader1(String), PluginHeader2(long)
>
> Consumer(Openwire)
> Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are
> present)
>
> Additional info:
> If browsing message in console on TEST: Headers :
> Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present)
> If the message is moved from TEST to TEST1 queue directly on the Web Console,
> the headers PluginHeader1, PluginHeader2 are lost on TEST1 queue.
>
> Scenario3
> --
> Producer(Openwire)
> Header1:String, Header2:long
>
> Plugin
> Adds two new headers PluginHeader1(String), PluginHeader2(long)
>
> Consumer(AMQP)
> Headers : Header1,Header2,PluginHeader1, PluginHeader2 (All headers are
> present)
>
> Additional info:
> If browsing message in console on TEST: Headers :
> Header1,Header2,PluginHeader1, PluginHeader2 (All headers are present)
> If the message is moved from TEST to TEST1 queue directly on the Web Console,
> all headers are present TEST1 queue.
>
> Thanks,
> Mohanavalli A
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQCPP-751) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/AMQCPP-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1762#comment-1762
]
Timothy A. Bish commented on AMQCPP-751:
As this issue continues to be a client issue I am moving to the CMS client
where a fix would need to be made to bring it into full compliance with other
Openwire clients in how multibyte strings are encoded.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: AMQCPP-751
> URL: https://issues.apache.org/jira/browse/AMQCPP-751
> Project: ActiveMQ C++ Client
> Issue Type: Bug
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
>
[jira] [Moved] (AMQCPP-751) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/AMQCPP-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish moved ARTEMIS-4462 to AMQCPP-751:
-
Key: AMQCPP-751 (was: ARTEMIS-4462)
Affects Version/s: (was: 2.30.0)
Workflow: classic default workflow (was: jira)
Project: ActiveMQ C++ Client (was: ActiveMQ Artemis)
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: AMQCPP-751
> URL: https://issues.apache.org/jira/browse/AMQCPP-751
> Project: ActiveMQ C++ Client
> Issue Type: Bug
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1295#comment-1295
]
Timothy A. Bish commented on ARTEMIS-4462:
--
As the person that wrote the majority of the CMS code I can tell that it does
not do any encoding of multi-byte string as at the time it was written (2005)
there was little to no cases where that was necessary and the C++ string types
made it painful to do anyway. This is fine if you don't play any games and try
to shoehorn in non-ASCII strings into the CMS TextMessage but since you are you
will likely hit issues as broker side and Java client side, the strings are
expected to be encoded an Modified UTF-8 if you are using multi byte
characters.
The ActiveMQ 5.x Broker itself will go out of its way not to decode the message
payload that is stored in the byte sequence that comprises the body. It could
do so if you used some broker plugins that triggered it so you are basically
playing with fire by doing what you are doing. The solution here as Robbie has
pointed out is to encode your strings into a BytesMessage which will pass
untouched in Artemis as the conversion to the native Core protocol can just
move those bytes into a Core message.
You other option is to modify the CMS client with API and handling to encode
wide character strings into modified UTF-8 payloads in the Openwire message
body to ensure they are compatible with not only Artemis but the ActiveMQ 5.x
broker as well.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
>
[jira] [Closed] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-4462.
Resolution: Information Provided
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>
[jira] [Closed] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-4462.
Resolution: Information Provided
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776657#comment-17776657
]
Timothy A. Bish commented on ARTEMIS-4462:
--
This is most likely the same issue as was reported AMQCPP-692 where the CMS
client does not properly encode the strings and this causes the exception as
the decoding will fail when Artemis is converting from Openwire native to the
Artemis native CORE message. This comes down to a bug in the client that
hasn't been fixed and since the client is no longer maintained it is unlikely
to ever be fixed. I probably can sneak by in a 5.x broker so long as the
message contents aren't decoded broker side but will likely throw an exception
if that happened.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
>
[jira] [Updated] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4462:
-
Description:
When a text message non-UTF-8 (ISO-8859-15) containing special characters is
sent from ActiveMQ CPP client to Artemis, an exception
"java.io.UTFDataFormatException" is seen in Artemis server log.
Although the exception is thrown as a warning, the message gets rejected by the
server.
Below the Artemis server log:
{noformat}
2023-09-29 11:34:32,736 WARN
[org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors
occurred during the buffering operation
java.io.UTFDataFormatException: null
at
org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
~[activemq-client-5.17.2.jar:5.17.2]
at
org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
~[activemq-client-5.17.2.jar:5.17.2]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
~[activemq-client-5.17.2.jar:5.17.2]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.30.0.jar:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
[?:?]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.30.0.jar:?]
2023-09-29 11:34:32,753 WARN
[org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors
occurred during the buffering operation
org.apache.activemq.artemis.api.core.ActiveMQException: null
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
~[activemq-client-5.17.2.jar:5.17.2]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at
org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
~[artemis-commons-2.30.0.jar:?]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
~[artemis-commons-2.30.0.jar:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
[?:?]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.30.0.jar:?]
2023-09-29 11:34:32,755 WARN
[org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors
occurred during the buffering operation
java.io.UTFDataFormatException: null
{noformat}
Just create a small test program using
[jira] [Updated] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[ https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4462: - Description: When a text message non-UTF-8 (ISO-8859-15) containing special characters is sent from ActiveMQ CPP client to Artemis, an exception "java.io.UTFDataFormatException" is seen in Artemis server log. Although the exception is thrown as a warning, the message gets rejected by the server. Below the Artemis server log: _2023-09-29 11:34:32,736 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation_ _java.io.UTFDataFormatException: null_ _at org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386) ~[activemq-client-5.17.2.jar:5.17.2]_ _at org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) ~[activemq-client-5.17.2.jar:5.17.2]_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) ~[activemq-client-5.17.2.jar:5.17.2]_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]_ _at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]_ _at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.30.0.jar:?]_ _2023-09-29 11:34:32,753 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation_ _org.apache.activemq.artemis.api.core.ActiveMQException: null_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) ~[activemq-client-5.17.2.jar:5.17.2]_ _at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]_ _at org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) ~[artemis-commons-2.30.0.jar:?]_ _at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]_ _at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]_ _at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]_ _at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.30.0.jar:?]_ _2023-09-29 11:34:32,755 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation_
[jira] [Created] (ARTEMIS-4431) AMQP federated address consumer not applying hops annotation correctly
Timothy A. Bish created ARTEMIS-4431: Summary: AMQP federated address consumer not applying hops annotation correctly Key: ARTEMIS-4431 URL: https://issues.apache.org/jira/browse/ARTEMIS-4431 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.30.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.31.0 The AMQP federation address consumer omits a call to re-encode the message after updating the hops annotation that track how many federation links the message has traversed. This results in the message not carrying forward the correct annotation which breaks the max hops configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4217) AMQ111005: Failed to convert message. Sending it to Dead Letter Address.
[
https://issues.apache.org/jira/browse/ARTEMIS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764730#comment-17764730
]
Timothy A. Bish commented on ARTEMIS-4217:
--
[~jbertram] Just as a note there is one case where this could happen and that
is if the 'amqpMinLargeMessageSize' is set larger than the journal max file
size (not sure the exact name) which causes a message that wasn't 'large' to
become large but uses an AMQP to Core conversion as opposed to a simple convert
from a "standard" AMQP message to a "large" AMQP message. This would result in
the back to AMQP from Core case in cases where you might not be expecting it
which could lead to a way to reproduce this if that is indeed how this is
getting hit.
> AMQ111005: Failed to convert message. Sending it to Dead Letter Address.
>
>
> Key: ARTEMIS-4217
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4217
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.28.0
> Environment: Windows Server 2022 21H2
> openjdk 19.0.1 2022-10-18
> OpenJDK Runtime Environment (build 19.0.1+10-21)
> OpenJDK 64-Bit Server VM (build 19.0.1+10-21, mixed mode, sharing)
>Reporter: daves
>Priority: Major
> Attachments: ArtemisConvertError.zip,
> image-2023-06-16-15-59-25-689.png, image-2023-06-16-15-59-25-721.png
>
>
> Some of the AMQP messages sent by my client never arrive at the consumer. In
> the Artemis log I found the following exception:
> {noformat}
> 2023-03-23 18:06:58,084 WARN
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111005: Failed to
> convert message. Sending it to Dead Letter Address.
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.ConversionException:
> java.nio.channels.ClosedChannelException
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:318)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:79)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:561)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:131)
> ~[artemis-server-2.28.0.jar:2.28.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[artemis-commons-2.28.0.jar:?] Caused by: java.lang.RuntimeException:
> java.nio.channels.ClosedChannelException
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.LargeBody.getBodyBufferSize(LargeBody.java:293)
> ~[artemis-server-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.getBodyBufferSize(LargeServerMessageImpl.java:263)
> ~[artemis-server-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.getBodyLength(CoreBytesMessageWrapper.java:98)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.getBinaryFromMessageBody(CoreBytesMessageWrapper.java:68)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:78)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:106)
> ~[artemis-amqp-protocol-2.28.0.jar:2.28.0]
> ... 10 more
>
[jira] [Resolved] (ARTEMIS-4419) Add broker federation support to the AMQP broker connection feature-set
[ https://issues.apache.org/jira/browse/ARTEMIS-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish resolved ARTEMIS-4419. -- Resolution: Fixed > Add broker federation support to the AMQP broker connection feature-set > > > Key: ARTEMIS-4419 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4419 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Affects Versions: 2.30.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Add a feature element to the broker connection feature-set that allows for > broker federation over AMQP on outgoing AMQP broker connections. The feature > should support duplex federation across the same connection allowing > configuration of federation for local address and queues from a remote and > the reverse. The AMQP broker connection configuration should be updated to > allow configuring this feature in XML and using the broker properties > mechanism. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4419) Add broker federation support to the AMQP broker connection feature-set
Timothy A. Bish created ARTEMIS-4419: Summary: Add broker federation support to the AMQP broker connection feature-set Key: ARTEMIS-4419 URL: https://issues.apache.org/jira/browse/ARTEMIS-4419 Project: ActiveMQ Artemis Issue Type: New Feature Components: AMQP Affects Versions: 2.30.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.31.0 Add a feature element to the broker connection feature-set that allows for broker federation over AMQP on outgoing AMQP broker connections. The feature should support duplex federation across the same connection allowing configuration of federation for local address and queues from a remote and the reverse. The AMQP broker connection configuration should be updated to allow configuring this feature in XML and using the broker properties mechanism. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (AMQNET-835) Document deserialization policy
[ https://issues.apache.org/jira/browse/AMQNET-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish moved OPENWIRE-65 to AMQNET-835: Key: AMQNET-835 (was: OPENWIRE-65) Project: ActiveMQ .Net (was: ActiveMQ OpenWire) > Document deserialization policy > --- > > Key: AMQNET-835 > URL: https://issues.apache.org/jira/browse/AMQNET-835 > Project: ActiveMQ .Net > Issue Type: Improvement >Reporter: Arnout Engelen >Priority: Major > > Unrestricted deserialization of untrusted data is dangerous and can lead to > remote code execution attacks. > To be able to safely deserialize untrusted data, the Apache NMS ActiveMQ .Net > client introduced deserialization policy options in version 2.1.0 > ([https://www.mail-archive.com/dev@activemq.apache.org/msg68832.html]). > It would be good to call out in the documentation that if you want to accept > untrusted data, you should use these options. > (I hope this is the correct Jira project to report this to, if not let me > know and I'll re-file it to the correct one :)) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4282) Sending Large ApplicationProperties section in a transactional session may break the server.
[ https://issues.apache.org/jira/browse/ARTEMIS-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4282: - Summary: Sending Large ApplicationProperties section in a transactional session may break the server. (was: Sending Large ApplicationProperty section in a transactional session may break the server.) > Sending Large ApplicationProperties section in a transactional session may > break the server. > > > Key: ARTEMIS-4282 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4282 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4282) Sending Large ApplicationProperty section in a transactional session may break the server.
[ https://issues.apache.org/jira/browse/ARTEMIS-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4282: - Summary: Sending Large ApplicationProperty section in a transactional session may break the server. (was: Sending Large Header in a transactional session may break the server.) > Sending Large ApplicationProperty section in a transactional session may > break the server. > -- > > Key: ARTEMIS-4282 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4282 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4264) MQTT v5 request-response with correlation ID
[ https://issues.apache.org/jira/browse/ARTEMIS-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717774#comment-17717774 ] Timothy A. Bish commented on ARTEMIS-4264: -- You can look at Qpid JMS which handles some scenarios like this where the AMQP spec allows for several types including Binary and String along with UUID and ulong. Since I don't think MQTT defines what the correlation bytes mean you likely would just either carry them along untouched or encode them as a hex string depending on how core protocol carries the correlation ID value (you need some way to round trip them depending on how core manages them). > MQTT v5 request-response with correlation ID > > > Key: ARTEMIS-4264 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4264 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Daniel Martin >Priority: Major > > When sending messages from a JMS producer (ActiveMQ) to a MQTT consumer > (HiveMQ), using `setJMSReplyTo()` and `setJMSCorrelationID()` on the sending > side and `getResponseTopic()` and `getCorrelationData()` on the receiving > side, this information is not received by MQTT. > It seem to me that both protocols are pretty translatable into one another, > having pretty much the same concepts: > * > [https://activemq.apache.org/how-should-i-implement-request-response-with-jms] > * > [https://hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern|https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern] > I'd additionally ask: is MQTT version 5 truly supported? To what extent? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (AMQ-9251) address-setting w/ wildcard not in herited by actual address
[ https://issues.apache.org/jira/browse/AMQ-9251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed AMQ-9251. Resolution: Invalid This appears to be a mistaken issue that duplicates https://issues.apache.org/jira/browse/ARTEMIS-4260 > address-setting w/ wildcard not in herited by actual address > > > Key: AMQ-9251 > URL: https://issues.apache.org/jira/browse/AMQ-9251 > Project: ActiveMQ > Issue Type: Bug >Reporter: arne anka >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4234) EmbeddedActiveMQResource is able to receive only first message
[
https://issues.apache.org/jira/browse/ARTEMIS-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish reassigned ARTEMIS-4234:
Assignee: Timothy A. Bish
> EmbeddedActiveMQResource is able to receive only first message
> --
>
> Key: ARTEMIS-4234
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4234
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Dominik Kawczyński
>Assignee: Timothy A. Bish
>Priority: Major
>
> Hi,
> i have encountered a problem with embedded Artemis.
> Using *EmbeddedActiveMQResource* _receiveMessage_ method im able to receive
> only one message from queue.
> Please look at following code:
> {code:java}
> artemis.start()
> def firstMessage = 'test message 1'
> sendMessage(firstMessage, 'test_queue')
> def firstReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' FIRST MESSAGE:')
> println('' + firstReceivedMessage.stringBody)
> /*
> will work if artemis is restarted during test
> artemis.stop()
> artemis.start()
> */
> def secondMessage = 'test message 2'
> sendMessage(secondMessage, 'test_queue')
> def secondReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' SECOND MESSAGE:')
> println('' + secondReceivedMessage.stringBody)
> then:
> firstMessage == firstReceivedMessage.stringBody
> secondMessage == secondReceivedMessage.stringBody {code}
> I'm getting null as secondReceivedMessage, and NPE in effect later.
>
> The reason is (i assume) that first invocation is creating a consumer, that
> is getting second message, before i invoke receiveMessage method second time
> (i see in logs that second message was consumed)
>
> Is this expected behavior?
> receiveMessage is returning only one message, so my assumption was, that i
> can invoke it several times to retrieve consequential messages, and i have
> not found any documentation explaining current behavior.
>
> I have created repo with reproducible example:
> [https://github.com/dmkaw/embedded-artemis-issue]
>
> Thanks in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4234) EmbeddedActiveMQResource is able to receive only first message
[
https://issues.apache.org/jira/browse/ARTEMIS-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-4234:
-
Fix Version/s: 2.29.0
> EmbeddedActiveMQResource is able to receive only first message
> --
>
> Key: ARTEMIS-4234
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4234
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Dominik Kawczyński
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.29.0
>
>
> Hi,
> i have encountered a problem with embedded Artemis.
> Using *EmbeddedActiveMQResource* _receiveMessage_ method im able to receive
> only one message from queue.
> Please look at following code:
> {code:java}
> artemis.start()
> def firstMessage = 'test message 1'
> sendMessage(firstMessage, 'test_queue')
> def firstReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' FIRST MESSAGE:')
> println('' + firstReceivedMessage.stringBody)
> /*
> will work if artemis is restarted during test
> artemis.stop()
> artemis.start()
> */
> def secondMessage = 'test message 2'
> sendMessage(secondMessage, 'test_queue')
> def secondReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' SECOND MESSAGE:')
> println('' + secondReceivedMessage.stringBody)
> then:
> firstMessage == firstReceivedMessage.stringBody
> secondMessage == secondReceivedMessage.stringBody {code}
> I'm getting null as secondReceivedMessage, and NPE in effect later.
>
> The reason is (i assume) that first invocation is creating a consumer, that
> is getting second message, before i invoke receiveMessage method second time
> (i see in logs that second message was consumed)
>
> Is this expected behavior?
> receiveMessage is returning only one message, so my assumption was, that i
> can invoke it several times to retrieve consequential messages, and i have
> not found any documentation explaining current behavior.
>
> I have created repo with reproducible example:
> [https://github.com/dmkaw/embedded-artemis-issue]
>
> Thanks in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4234) EmbeddedActiveMQResource is able to receive only first message
[
https://issues.apache.org/jira/browse/ARTEMIS-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709480#comment-17709480
]
Timothy A. Bish commented on ARTEMIS-4234:
--
I took a quite look at the code for the EmbeddedActiveMQResource receive
methods and they are indeed a bit odd (and lacking docs to indicate what the
expectations should be). The receive method creates and internal receiver for
getting this singular message and then never closes it or stores it for
additional use so it would seem to be leaking receiver resources. At the very
least I'd have expected the code to close the receiver when done since the
intent of the implementation sort of leans that way.
> EmbeddedActiveMQResource is able to receive only first message
> --
>
> Key: ARTEMIS-4234
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4234
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Dominik Kawczyński
>Priority: Major
>
> Hi,
> i have encountered a problem with embedded Artemis.
> Using *EmbeddedActiveMQResource* _receiveMessage_ method im able to receive
> only one message from queue.
> Please look at following code:
> {code:java}
> artemis.start()
> def firstMessage = 'test message 1'
> sendMessage(firstMessage, 'test_queue')
> def firstReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' FIRST MESSAGE:')
> println('' + firstReceivedMessage.stringBody)
> /*
> will work if artemis is restarted during test
> artemis.stop()
> artemis.start()
> */
> def secondMessage = 'test message 2'
> sendMessage(secondMessage, 'test_queue')
> def secondReceivedMessage = artemis.receiveMessage('test_queue', 1000)
> println(' SECOND MESSAGE:')
> println('' + secondReceivedMessage.stringBody)
> then:
> firstMessage == firstReceivedMessage.stringBody
> secondMessage == secondReceivedMessage.stringBody {code}
> I'm getting null as secondReceivedMessage, and NPE in effect later.
>
> The reason is (i assume) that first invocation is creating a consumer, that
> is getting second message, before i invoke receiveMessage method second time
> (i see in logs that second message was consumed)
>
> Is this expected behavior?
> receiveMessage is returning only one message, so my assumption was, that i
> can invoke it several times to retrieve consequential messages, and i have
> not found any documentation explaining current behavior.
>
> I have created repo with reproducible example:
> [https://github.com/dmkaw/embedded-artemis-issue]
>
> Thanks in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4235) Losing bridge connection when sending map message.
[
https://issues.apache.org/jira/browse/ARTEMIS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708530#comment-17708530
]
Timothy A. Bish edited comment on ARTEMIS-4235 at 4/4/23 6:29 PM:
--
This happens because in openwire if the Map portion of the MapMessage is empty
nothing is sent for that section of the message which is fine as it is the
trailing section so the decoder for openwire simply checks if the content
section is null which it will be as the marshalling code will just stop at the
end of the encoded byte stream.
Since this occurs post conversion to core then I'd guess one of two things
could fix it, either the convert from Openwire to core can write the
DataConstants.NULL as the payload which should stop the TypeProperties from
reading further then that, or the TypeProperties could be update to handle
nothing in the body at all which is probably a less desirable behavioral change.
was (Author: tabish121):
This happens because in openwire if the Map portion of the MapMessage is empty
nothing is sent for that section of the message which is fine as it is the
trailing section so the decoder for openwire simply checks if the content
section is null which it will be as the marshalling code will just stop at the
end of the encoded byte stream. The Artemis code needs to check the buffer to
see if it is readable and if not then just stop.
> Losing bridge connection when sending map message.
> --
>
> Key: ARTEMIS-4235
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4235
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.27.0
> Environment: Windows 10
>Reporter: Peter Sunnerdahl
>Priority: Critical
> Attachments: TestMQ.java, broker.xml, testMQMap.xml
>
>
> Artemis 2.27.0 installations with a bridge configured. When sending a map
> message with an empty map the message is sent to DLQ and the connection is
> lost. It will not recover unless I delete the message and restarts the
> service. Same testcase works on old ActiveMQ. Found this when upgrading.
> {noformat}
> 2023-04-03 14:17:59,339 WARN
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111005: Failed to
> convert message. Sending it to Dead Letter Address.
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.ConversionException:
> readerIndex(0) + length(1) exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0,
> widx: 0, cap: 0/0, unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap:
> 0/0, unwrapped:
> UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx:
> 1096, cap: 1096)))
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:319)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:80)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:541)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:134)
> ~[artemis-server-2.27.0.jar:2.27.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> ~[netty-transport-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[artemis-commons-2.27.0.jar:?]
> Caused by: java.lang.IndexOutOfBoundsException: readerIndex(0) + length(1)
> exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0, widx: 0, cap: 0/0,
> unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped:
> UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx:
> 1096, cap: 1096)))
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
> ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
> at
[jira] [Commented] (ARTEMIS-4235) Losing bridge connection when sending map message.
[
https://issues.apache.org/jira/browse/ARTEMIS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708530#comment-17708530
]
Timothy A. Bish commented on ARTEMIS-4235:
--
This happens because in openwire if the Map portion of the MapMessage is empty
nothing is sent for that section of the message which is fine as it is the
trailing section so the decoder for openwire simply checks if the content
section is null which it will be as the marshalling code will just stop at the
end of the encoded byte stream. The Artemis code needs to check the buffer to
see if it is readable and if not then just stop.
> Losing bridge connection when sending map message.
> --
>
> Key: ARTEMIS-4235
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4235
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.27.0
> Environment: Windows 10
>Reporter: Peter Sunnerdahl
>Priority: Critical
> Attachments: TestMQ.java, broker.xml, testMQMap.xml
>
>
> Artemis 2.27.0 installations with a bridge configured. When sending a map
> message with an empty map the message is sent to DLQ and the connection is
> lost. It will not recover unless I delete the message and restarts the
> service. Same testcase works on old ActiveMQ. Found this when upgrading.
> {noformat}
> 2023-04-03 14:17:59,339 WARN
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111005: Failed to
> convert message. Sending it to Dead Letter Address.
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.ConversionException:
> readerIndex(0) + length(1) exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0,
> widx: 0, cap: 0/0, unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap:
> 0/0, unwrapped:
> UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx:
> 1096, cap: 1096)))
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:319)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:80)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:541)
> ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:134)
> ~[artemis-server-2.27.0.jar:2.27.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
> ~[netty-transport-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[artemis-commons-2.27.0.jar:?]
> Caused by: java.lang.IndexOutOfBoundsException: readerIndex(0) + length(1)
> exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0, widx: 0, cap: 0/0,
> unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped:
> UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx:
> 1096, cap: 1096)))
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
> ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
> at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730)
> ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
> at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529)
> ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
> at
> org.apache.activemq.artemis.utils.collections.TypedProperties.decode(TypedProperties.java:464)
> ~[artemis-commons-2.27.0.jar:?]
> at
> org.apache.activemq.artemis.utils.collections.TypedProperties.decode(TypedProperties.java:547)
> ~[artemis-commons-2.27.0.jar:?]
> at
> org.apache.activemq.artemis.reader.MapMessageUtil.readBodyMap(MapMessageUtil.java:46)
> ~[artemis-core-client-2.27.0.jar:2.27.0]
> at
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMapMessageWrapper.decode(CoreMapMessageWrapper.java:222)
>
[jira] [Commented] (ARTEMIS-4217) AMQ111005: Failed to convert message. Sending it to Dead Letter Address.
[
https://issues.apache.org/jira/browse/ARTEMIS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704306#comment-17704306
]
Timothy A. Bish commented on ARTEMIS-4217:
--
You could potentially work around this for now by increasing the
'{{{}minLargeMessageSize{}}}' option to avoid having core large messages which
get converted to AMQP messages as they cross to the AMQP client.
> AMQ111005: Failed to convert message. Sending it to Dead Letter Address.
>
>
> Key: ARTEMIS-4217
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4217
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.28.0
> Environment: Windows Server 2022 21H2
> openjdk 19.0.1 2022-10-18
> OpenJDK Runtime Environment (build 19.0.1+10-21)
> OpenJDK 64-Bit Server VM (build 19.0.1+10-21, mixed mode, sharing)
>Reporter: daves
>Priority: Major
> Attachments: artemis-service.wrapper.log, artemis.log,
> artemis.log.2023-03-23-1.log.gz, artemis.log.2023-03-23-10.log.gz,
> artemis.log.2023-03-23-100.log.gz, artemis.log.2023-03-23-11.log.gz,
> artemis.log.2023-03-23-12.log.gz, artemis.log.2023-03-23-13.log.gz,
> artemis.log.2023-03-23-14.log.gz, artemis.log.2023-03-23-15.log.gz,
> artemis.log.2023-03-23-16.log.gz, artemis.log.2023-03-23-17.log.gz,
> artemis.log.2023-03-23-18.log.gz, artemis.log.2023-03-23-19.log.gz,
> artemis.log.2023-03-23-2.log.gz, artemis.log.2023-03-23-20.log.gz,
> artemis.log.2023-03-23-21.log.gz, artemis.log.2023-03-23-22.log.gz,
> artemis.log.2023-03-23-23.log.gz, artemis.log.2023-03-23-24.log.gz,
> artemis.log.2023-03-23-25.log.gz, artemis.log.2023-03-23-26.log.gz,
> artemis.log.2023-03-23-27.log.gz, artemis.log.2023-03-23-28.log.gz,
> artemis.log.2023-03-23-29.log.gz, artemis.log.2023-03-23-3.log.gz,
> artemis.log.2023-03-23-30.log.gz, artemis.log.2023-03-23-31.log.gz,
> artemis.log.2023-03-23-32.log.gz, artemis.log.2023-03-23-33.log.gz,
> artemis.log.2023-03-23-34.log.gz, artemis.log.2023-03-23-35.log.gz,
> artemis.log.2023-03-23-36.log.gz, artemis.log.2023-03-23-37.log.gz,
> artemis.log.2023-03-23-38.log.gz, artemis.log.2023-03-23-39.log.gz,
> artemis.log.2023-03-23-4.log.gz, artemis.log.2023-03-23-40.log.gz,
> artemis.log.2023-03-23-41.log.gz, artemis.log.2023-03-23-42.log.gz,
> artemis.log.2023-03-23-43.log.gz, artemis.log.2023-03-23-44.log.gz,
> artemis.log.2023-03-23-45.log.gz, artemis.log.2023-03-23-46.log.gz,
> artemis.log.2023-03-23-47.log.gz, artemis.log.2023-03-23-48.log.gz,
> artemis.log.2023-03-23-49.log.gz, artemis.log.2023-03-23-5.log.gz,
> artemis.log.2023-03-23-50.log.gz, artemis.log.2023-03-23-51.log.gz,
> artemis.log.2023-03-23-52.log.gz, artemis.log.2023-03-23-53.log.gz,
> artemis.log.2023-03-23-54.log.gz, artemis.log.2023-03-23-55.log.gz,
> artemis.log.2023-03-23-56.log.gz, artemis.log.2023-03-23-57.log.gz,
> artemis.log.2023-03-23-58.log.gz, artemis.log.2023-03-23-59.log.gz,
> artemis.log.2023-03-23-6.log.gz, artemis.log.2023-03-23-60.log.gz,
> artemis.log.2023-03-23-61.log.gz, artemis.log.2023-03-23-62.log.gz,
> artemis.log.2023-03-23-63.log.gz, artemis.log.2023-03-23-64.log.gz,
> artemis.log.2023-03-23-65.log.gz, artemis.log.2023-03-23-66.log.gz,
> artemis.log.2023-03-23-67.log.gz, artemis.log.2023-03-23-68.log.gz,
> artemis.log.2023-03-23-69.log.gz, artemis.log.2023-03-23-7.log.gz,
> artemis.log.2023-03-23-70.log.gz, artemis.log.2023-03-23-71.log.gz,
> artemis.log.2023-03-23-72.log.gz, artemis.log.2023-03-23-73.log.gz,
> artemis.log.2023-03-23-74.log.gz, artemis.log.2023-03-23-75.log.gz,
> artemis.log.2023-03-23-76.log.gz, artemis.log.2023-03-23-77.log.gz,
> artemis.log.2023-03-23-78.log.gz, artemis.log.2023-03-23-79.log.gz,
> artemis.log.2023-03-23-8.log.gz, artemis.log.2023-03-23-80.log.gz,
> artemis.log.2023-03-23-81.log.gz, artemis.log.2023-03-23-82.log.gz,
> artemis.log.2023-03-23-83.log.gz, artemis.log.2023-03-23-84.log.gz,
> artemis.log.2023-03-23-85.log.gz, artemis.log.2023-03-23-86.log.gz,
> artemis.log.2023-03-23-87.log.gz, artemis.log.2023-03-23-88.log.gz,
> artemis.log.2023-03-23-89.log.gz, artemis.log.2023-03-23-9.log.gz,
> artemis.log.2023-03-23-90.log.gz, artemis.log.2023-03-23-91.log.gz,
> artemis.log.2023-03-23-92.log.gz, artemis.log.2023-03-23-93.log.gz,
> artemis.log.2023-03-23-94.log.gz, artemis.log.2023-03-23-95.log.gz,
> artemis.log.2023-03-23-96.log.gz, artemis.log.2023-03-23-97.log.gz,
> artemis.log.2023-03-23-98.log.gz, artemis.log.2023-03-23-99.log.gz
>
>
> Some of the AMQP messages sent by my client never arrive at the consumer. In
> the Artemis log I found the following exception:
>
>
> {code:java}
> 2023-03-23 18:06:58,084 WARN
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111005: Failed to
> convert message. Sending
[jira] [Created] (ARTEMIS-4178) Fixing typo on amqp-broker-connections.md
Timothy A. Bish created ARTEMIS-4178: Summary: Fixing typo on amqp-broker-connections.md Key: ARTEMIS-4178 URL: https://issues.apache.org/jira/browse/ARTEMIS-4178 Project: ActiveMQ Artemis Issue Type: Task Components: AMQP Affects Versions: 2.28.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.29.0 Fixing some minor typos in amqp-broker-connections.md -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-771) Can't use wildcard topic subscription with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish closed ARTEMIS-771. --- Resolution: Cannot Reproduce I've tested this both with auto create enabled and disabled where I created the necessary addresses and it works as expected, closing as it likely was addressed by other changes over time. > Can't use wildcard topic subscription with AMQP > --- > > Key: ARTEMIS-771 > URL: https://issues.apache.org/jira/browse/ARTEMIS-771 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Reporter: Gordon Sim >Assignee: Martyn Taylor >Priority: Major > > I want to use wildcarded topic subscriptions with AMQP. I.e. I want to > receive from topic.news.# and send to either topic.news.usa or > topics.news.europe, and have my receiver see all matching messages. > However I get a not-found exception when trying to attach a sender to either > topic.news.use or topic.news.europe. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4130) failed amqp connect attempt leads to 3 stack traces in log
[
https://issues.apache.org/jira/browse/ARTEMIS-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683459#comment-17683459
]
Timothy A. Bish commented on ARTEMIS-4130:
--
There is a relation to ARTEMIS-2431 though in that the error condition that's
getting returned from pipelined open should not be about an NPE etc but should
indicate the access violation which it now does.
> failed amqp connect attempt leads to 3 stack traces in log
> --
>
> Key: ARTEMIS-4130
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4130
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.27.1
>Reporter: Erwin Dondorp
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> context:
> * server login.conf allows only "PropertiesLoginModule required" (i.e.
> username+password only)
> * client is using AMQP with Python Proton library
> * client is connecting anonymously to this server
> the connect attempt is supposed to fail because it is trying anonymous login
> on a server that does not allow that. but that is not the problem.
> instead of a simple rejected login, this results in 3 stack traces in the
> artemis server logfile per connect attempt. the client still gets its
> rejection, but in the form of a "amqp:internal-error / Unrecoverable error:
> NullPointerException".
> this is the log for a single connect attempt:
> {noformat}
> 2023-01-15 12:46:35,847 WARN [org.apache.activemq.artemis.core.server]
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /10.11.1.3:62895. Username: null; SSL certificate subject
> DN: unavailable
> 2023-01-15 12:46:35,847 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext]
> AMQ229031: Unable to validate user from /10.11.1.3:62895. Username: null; SSL
> certificate subject DN: unavailable
> org.apache.activemq.artemis.api.core.ActiveMQSecurityException: AMQ229031:
> Unable to validate user from /10.11.1.3:62895. Username: null; SSL
> certificate subject DN: unavailable
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticationFailed(SecurityStoreImpl.java:360)
> ~[artemis-server-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:189)
> ~[artemis-server-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.validateUser(ActiveMQServerImpl.java:1744)
> ~[artemis-server-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.validateUser(AMQPConnectionContext.java:595)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onRemoteOpen(AMQPConnectionContext.java:553)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:32)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:565)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:361)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:318)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:242)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:134)
> ~[artemis-amqp-protocol-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:691)
> ~[artemis-server-2.27.1.jar:2.27.1]
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> ~[artemis-core-client-2.27.1.jar:2.27.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> ~[netty-transport-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> ~[netty-transport-4.1.82.Final.jar:4.1.82.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>
[jira] [Assigned] (ARTEMIS-2431) [AMQP] Broker does not send security errors for unauthorized anonymous sasl with pipelined open
[
https://issues.apache.org/jira/browse/ARTEMIS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish reassigned ARTEMIS-2431:
Assignee: Timothy A. Bish
> [AMQP] Broker does not send security errors for unauthorized anonymous sasl
> with pipelined open
> ---
>
> Key: ARTEMIS-2431
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2431
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.9.0
>Reporter: Jiri Daněk
>Assignee: Timothy A. Bish
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If a client sends open, begin and attach frames all at once, then the issue
> ARTEMIS-2344 still manifests itself. Sending the initial frames all at once
> is known as the pipelined open,
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp157520
> and one client that does this is qpid-proton-cpp.
> {noformat}
> $ PN_TRACE_FRM=1 ./target/bin/aac3_sender -b "localhost:34949/examples"
> --log-msgs dict -c 1
> [0x9ea9d0]: -> SASL
> [0x9ea9d0]: <- SASL
> [0x9ea9d0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x9ea9d0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@nixos"]
> [0x9ea9d0]:0 <- @sasl-outcome(68) [code=0]
> [0x9ea9d0]: -> AMQP
> [0x9ea9d0]:0 -> @open(16)
> [container-id="204c1d45-9c47-402d-809f-7d17a4d97d6e", hostname="localhost",
> channel-max=32767]
> [0x9ea9d0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=2147483647]
> [0x9ea9d0]:0 -> @attach(18) [name="2b46ad5b-834b-454e-a2f7-2e5e0e324e21",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="examples", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0, max-message-size=0]
> [0x9ea9d0]: <- AMQP
> [0x9ea9d0]:0 <- @open(16) [container-id="localhost", max-frame-size=131072,
> channel-max=65535, idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis", :version="2.9.0"}]
> [0x9ea9d0]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:internal-error", description="Unrecoverable error:
> NullPointerException"]]
> [0x9ea9d0]: <- EOS
> [error]: Failed to connect to localhost:34949
> [0x9ea9d0]:0 -> @close(24) []
> [0x9ea9d0]: -> EOS
> {noformat}
> The broker side then looks like this
> {noformat}
> DEBUG - -Dio.netty.recycler.maxCapacityPerThread: 4096
> DEBUG - -Dio.netty.recycler.maxSharedCapacityFactor: 2
> DEBUG - -Dio.netty.recycler.linkCapacity: 16
> DEBUG - -Dio.netty.recycler.ratio: 8
> DEBUG - onSaslInit: SaslImpl [_outcome=PN_SASL_NONE, state=PN_SASL_STEP,
> done=false, role=SERVER]
> DEBUG - saslComplete: SaslImpl [_outcome=PN_SASL_NONE, state=PN_SASL_STEP,
> done=false, role=SERVER]
> DEBUG - using hardware address 2:42:ffbb:ffa4:4d:-110
> INFO - AMQ601267: User anonymous is creating a core session on target
> resource ActiveMQServerImpl::serverUUID=85b3269d-8773-11e9-8808-c0b6f9980288
> [with parameters: [dbdce52b-ae0f-11e9-8b93-0242bba44d92, null, , 102400,
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection@26c5379b,
> false, false, false, true, null,
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback@673826ee,
> true, OperationContextImpl [834445691] [minimalStore=9223372036854775807,
> storeLineUp=0, stored=0, minimalReplicated=9223372036854775807,
> replicationLineUp=0, replicated=0, paged=0, minimalPage=9223372036854775807,
> pageLineUp=0, errorCode=-1, errorMessage=null, executorsPending=0,
> executor=OrderedExecutor(tasks=[])], {}]]
> DEBUG - Couldn't validate user
> javax.security.auth.login.LoginException: Invalid null input: name
> at javax.security.auth.login.LoginContext.init(LoginContext.java:238)
> at javax.security.auth.login.LoginContext.(LoginContext.java:512)
> at
> org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.getAuthenticatedSubject(ActiveMQJAASSecurityManager.java:190)
> at
> org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.validateUser(ActiveMQJAASSecurityManager.java:99)
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:137)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1519)
> at
>
[jira] [Updated] (ARTEMIS-3178) Provide a way to limit the size of an address after paged
[ https://issues.apache.org/jira/browse/ARTEMIS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-3178: - Description: I am adding three attributes to Address-settings: * page-limit-bytes: Number of bytes. We will convert this metric into max number of pages internally by dividing max-bytes / page-size. It will allow a max based on an estimate. * page-limit-messages: Number of messages * page-full-message-policy: fail : drop We will now allow paging, until these max values and then fail or drop messages. Once these values are retracted, the address will remain full until a period where cleanup is kicked in by paging. So these values may have a certain delay on being applied, but they should always be cleared once cleanup happened. was: I am adding three attributes to Address-settings: page-limit-bytes: Number of bytes. We will convert this metric into max number of pages internally by dividing max-bytes / page-size. It will allow a max based on an estimate. page-limit-messages: Number of messages page-full-message-policy: fail : drop We will now allow paging, until these max values and then fail or drop messages. Once these values are retracted, the address will remain full until a period where cleanup is kicked in by paging. So these values may have a certain delay on being applied, but they should always be cleared once cleanup happened. > Provide a way to limit the size of an address after paged > - > > Key: ARTEMIS-3178 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3178 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.17.0 >Reporter: Gary Tully >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > I am adding three attributes to Address-settings: > * page-limit-bytes: Number of bytes. We will convert this metric into max > number of pages internally by dividing max-bytes / page-size. It will allow a > max based on an estimate. > * page-limit-messages: Number of messages > * page-full-message-policy: fail : drop > We will now allow paging, until these max values and then fail or drop > messages. > Once these values are retracted, the address will remain full until a period > where cleanup is kicked in by paging. So these values may have a certain > delay on being applied, but they should always be cleared once cleanup > happened. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3153) Broker doesn't respect prefixes from AMQP client
[
https://issues.apache.org/jira/browse/ARTEMIS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish closed ARTEMIS-3153.
Resolution: Cannot Reproduce
Closing as tests added show this to be working, can be reopened if new data is
presented that provides a means of recreating the issue
> Broker doesn't respect prefixes from AMQP client
>
>
> Key: ARTEMIS-3153
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3153
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Reporter: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The broker doesn't appear to respect an AMQP client using a prefix (e.g.
> {{anycast://}} or {{multicast://}}) when sending or consuming messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3153) Broker doesn't respect prefixes from AMQP client
[
https://issues.apache.org/jira/browse/ARTEMIS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681371#comment-17681371
]
Timothy A. Bish commented on ARTEMIS-3153:
--
I'd probably consider closing this as cannot reproduce unless there is more
information provided, I did find a different but unrelated issue that I'm
looking at but this one seems to work so long as you've configured the broker
properly.
> Broker doesn't respect prefixes from AMQP client
>
>
> Key: ARTEMIS-3153
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3153
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Reporter: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The broker doesn't appear to respect an AMQP client using a prefix (e.g.
> {{anycast://}} or {{multicast://}}) when sending or consuming messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3153) Broker doesn't respect prefixes from AMQP client
[
https://issues.apache.org/jira/browse/ARTEMIS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-3153:
-
Component/s: AMQP
> Broker doesn't respect prefixes from AMQP client
>
>
> Key: ARTEMIS-3153
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3153
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Reporter: Justin Bertram
>Priority: Major
>
> The broker doesn't appear to respect an AMQP client using a prefix (e.g.
> {{anycast://}} or {{multicast://}}) when sending or consuming messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3153) Broker doesn't respect prefixes from AMQP client
[
https://issues.apache.org/jira/browse/ARTEMIS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680623#comment-17680623
]
Timothy A. Bish commented on ARTEMIS-3153:
--
There is a relation to the behaviours discussed above:
{quote}
* consumer without prefix: FAIL, address and queue are created, but as
ANYCAST; should have been MULTICAST as per the default-routing-type
{quote}
This case is an expression of ARTEMIS-4132 which if tested again in a new
release will now pass leaving the remaining failures.
> Broker doesn't respect prefixes from AMQP client
>
>
> Key: ARTEMIS-3153
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3153
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Priority: Major
>
> The broker doesn't appear to respect an AMQP client using a prefix (e.g.
> {{anycast://}} or {{multicast://}}) when sending or consuming messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
