[jira] [Updated] (ARTEMIS-4423) Upgrade Netty to 4.1.97.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino updated ARTEMIS-4423: - Fix Version/s: 2.31.0 (was: 2.30.0) > Upgrade Netty to 4.1.97.Final > - > > Key: ARTEMIS-4423 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4423 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Assignee: Justin Bertram >Priority: Major > Fix For: 2.31.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4423) Upgrade Netty to 4.1.97.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762952#comment-17762952 ] ASF subversion and git services commented on ARTEMIS-4423: -- Commit bbe23b24ad77c2bad5ce2b75c873016adeb8943c in activemq-artemis's branch refs/heads/main from Emmanuel Hugonnet [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=bbe23b24ad ] ARTEMIS-4423 upgrade Netty to 4.1.97.Final Signed-off-by: Emmanuel Hugonnet > Upgrade Netty to 4.1.97.Final > - > > Key: ARTEMIS-4423 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4423 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Assignee: Justin Bertram >Priority: Major > Fix For: 2.30.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQNET-606) Wrong behavior when server sends DeliveryState Modified with DeliveryFailed=true as a reply to Ack
[ https://issues.apache.org/jira/browse/AMQNET-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762937#comment-17762937 ] ASF subversion and git services commented on AMQNET-606: Commit 4f3b0dacab358c9cba5decea1ac2add17063c76b in activemq-nms-amqp's branch refs/heads/main from Jefwillems [ https://gitbox.apache.org/repos/asf?p=activemq-nms-amqp.git;h=4f3b0da ] AMQNET-606: Ignore can be removed. test works > Wrong behavior when server sends DeliveryState Modified with > DeliveryFailed=true as a reply to Ack > -- > > Key: AMQNET-606 > URL: https://issues.apache.org/jira/browse/AMQNET-606 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Affects Versions: 1.8.0 >Reporter: Krzysztof Porębski >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > When server sends Modified with DeliveryFailed=true as a reply to Ack, > exception should be thrown the same way as for Rejected and Released frames. > Failing unit test: FailoverIntegrationTest.cs > TestFailoverPassthroughOfModifiedFailedSyncSend -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AMQ-9300) hawtio console embedded in ActiveMQ classic showing only connect button
[
https://issues.apache.org/jira/browse/AMQ-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianandrea Rigoni resolved AMQ-9300.
Resolution: Information Provided
> hawtio console embedded in ActiveMQ classic showing only connect button
> ---
>
> Key: AMQ-9300
> URL: https://issues.apache.org/jira/browse/AMQ-9300
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.17.4, 5.17.5, 5.18.2
>Reporter: Gianandrea Rigoni
>Priority: Major
> Attachments: 260776996-d66d2565-7534-4685-8e8a-4f3704c80df3.png
>
>
> hello folks
> *what worked*
> with versions
> ActiveMQ 5.17.3 and jetty JAAS jar 9.4.49.v20220914
> HAWTIO from version 2.16.3 to 2.17.6
> I am able +flawlessly to display HAWTIO+ console with all the queues
> (long ago I started to use instructions from
> https://bennet-schulz.com/2016/07/apache-activemq-and-hawtio.html)
> (I've LDAP plugin installed for the authentication)
> *now the problem*
> since AMQ 5.17.4 (jetty JAAS jar 9.4.50.v20221201) and HAWTIO from version
> 2.16.3 to 2.17.6:
> the only thing that I get in browser is shown in attached screenshot
> i.e. the add connection button
> also AMQ versions 5.17.5 and 5.18.2 show the same behaviour
> in both cases ("hawtio working" and "hawtio non working") AMQ broker and
> jolokia are functioning as expected)
> is this a bug or I missed some breaking changes?
> thanks for any advice
> best regards
> Gianandrea
> PS: not knowing/understanding where the problem is, I've reported it in
> hawtio project(https://github.com/hawtio/hawtio/issues/2917) too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9300) hawtio console embedded in ActiveMQ classic showing only connect button
[
https://issues.apache.org/jira/browse/AMQ-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762871#comment-17762871
]
Gianandrea Rigoni commented on AMQ-9300:
-
[~nfilotto] it worked like a charm! thank you so much for the precise and
detailed solution
> hawtio console embedded in ActiveMQ classic showing only connect button
> ---
>
> Key: AMQ-9300
> URL: https://issues.apache.org/jira/browse/AMQ-9300
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.17.4, 5.17.5, 5.18.2
>Reporter: Gianandrea Rigoni
>Priority: Major
> Attachments: 260776996-d66d2565-7534-4685-8e8a-4f3704c80df3.png
>
>
> hello folks
> *what worked*
> with versions
> ActiveMQ 5.17.3 and jetty JAAS jar 9.4.49.v20220914
> HAWTIO from version 2.16.3 to 2.17.6
> I am able +flawlessly to display HAWTIO+ console with all the queues
> (long ago I started to use instructions from
> https://bennet-schulz.com/2016/07/apache-activemq-and-hawtio.html)
> (I've LDAP plugin installed for the authentication)
> *now the problem*
> since AMQ 5.17.4 (jetty JAAS jar 9.4.50.v20221201) and HAWTIO from version
> 2.16.3 to 2.17.6:
> the only thing that I get in browser is shown in attached screenshot
> i.e. the add connection button
> also AMQ versions 5.17.5 and 5.18.2 show the same behaviour
> in both cases ("hawtio working" and "hawtio non working") AMQ broker and
> jolokia are functioning as expected)
> is this a bug or I missed some breaking changes?
> thanks for any advice
> best regards
> Gianandrea
> PS: not knowing/understanding where the problem is, I've reported it in
> hawtio project(https://github.com/hawtio/hawtio/issues/2917) too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762861#comment-17762861
]
Justin Bertram edited comment on ARTEMIS-4416 at 9/7/23 8:33 PM:
-
As noted in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/jms-core-mapping.html]:
bq. ...a JMS queue is implemented as an address with name=(the JMS queue name)
with an ANYCAST routing type associated with it.
Therefore, when an application uses the core JMS client to send a message to a
JMS queue then the implementation will check if there is an address and anycast
queue with the proper name. If there isn't then it will attempt to auto-create
one or both as necessary. If auto-creation of the address or queue is not
possible then the implementation will thrown an exception indicating that the
destination is invalid. This is to fulfill the expectation that sending a
message to a JMS queue will actually result in the message being stored.
This is in contrast to sending a message to a JMS _topic_ where it's perfectly
acceptable for the message not be stored (i.e. if there are no subscriptions).
In your case, your application is sending a message to a JMS queue named
{{myAddress}}. On the broker you have defined an address named {{myAddress}},
but you _don't_ have a corresponding anycast queue named {{myAddress}} and
since auto-creation for queues is also disabled you receive an invalid
destination exception since the client has no expectation that the message will
actually be stored on the broker.
bq. It's the server's responsibility to forward the message to the correct
queue, if the queue doesn't exist, it will send the message to DLQ or elsewhere.
This is incorrect. If there is no queue on an address or if there are queues
with filters and the sent message doesn't match then the message _will be
dropped_ by default.
Prior to 2.7.0 the client wouldn't even attempt to auto-create the queue so it
was possible for messages to essentially be lost (i.e. sent to the broker
"successfully" but dropped).
If you want to keep your existing semantics you just need to use a JMS topic &
multicast, e.g.:
{code:java}
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://localhost:61616");
JmsTemplate jmsTemplate = new JmsTemplate(connectionFactory);
jmsTemplate.setDefaultDestination(new ActiveMQTopic("myAddress")); // use a JMS
topic
jmsTemplate.send(msg -> {
TextMessage textMessage = msg.createTextMessage("body-content-text");
textMessage.setStringProperty("foo", "3");
return textMessage;
});{code}
{code:xml}
{code}
It's worth noting that having multiple _anycast_ queues on an address is rather
uncommon. In your case the only reason it's working is because all the filters
are mutually exclusive. I would definitely recommend using a JMS topic and
multicast configuration as it actually fits your use-case.
Also, I recommend you keep your broker more up-to-date. This change was
introduced over 4 years ago now.
was (Author: jbertram):
As noted in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/jms-core-mapping.html]:
bq. ...a JMS queue is implemented as an address with name=(the JMS queue name)
with an ANYCAST routing type associated with it.
Therefore, when an application uses the core JMS client to send a message to a
JMS queue then the implementation will check if there is an address and anycast
queue with the proper name. If there isn't then it will attempt to auto-create
one or both as necessary. If auto-creation of the address or queue is not
possible then the implementation will thrown an exception indicating that the
destination is invalid. This is to fulfill the expectation that sending a
message to a JMS queue will actually result in the message being stored.
This is in contrast to sending a message to a JMS _topic_ where it's perfectly
acceptable for the message not be stored (i.e. if there are no subscriptions).
In your case, your application is sending a message to a JMS queue named
{{myAddress}}. On the broker you have defined an address named {{myAddress}},
but you _don't_ have a corresponding anycast queue named {{myAddress}} and
since auto-creation for queues is also disabled you receive an invalid
destination exception since the client has no expectation that the message will
actually be stored on the broker.
bq. It's the server's responsibility to forward the message to the correct
queue, if the queue doesn't exist, it will send the message to DLQ or elsewhere.
This is incorrect. If there is no queue on an address or if there are queues
[jira] [Commented] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762861#comment-17762861
]
Justin Bertram commented on ARTEMIS-4416:
-
As noted in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/jms-core-mapping.html]:
bq. ...a JMS queue is implemented as an address with name=(the JMS queue name)
with an ANYCAST routing type associated with it.
Therefore, when an application uses the core JMS client to send a message to a
JMS queue then the implementation will check if there is an address and anycast
queue with the proper name. If there isn't then it will attempt to auto-create
one or both as necessary. If auto-creation of the address or queue is not
possible then the implementation will thrown an exception indicating that the
destination is invalid. This is to fulfill the expectation that sending a
message to a JMS queue will actually result in the message being stored.
This is in contrast to sending a message to a JMS _topic_ where it's perfectly
acceptable for the message not be stored (i.e. if there are no subscriptions).
In your case, your application is sending a message to a JMS queue named
{{myAddress}}. On the broker you have defined an address named {{myAddress}},
but you _don't_ have a corresponding anycast queue named {{myAddress}} and
since auto-creation for queues is also disabled you receive an invalid
destination exception since the client has no expectation that the message will
actually be stored on the broker.
bq. It's the server's responsibility to forward the message to the correct
queue, if the queue doesn't exist, it will send the message to DLQ or elsewhere.
This is incorrect. If there is no queue on an address or if there are queues
with filters and the sent message doesn't match then the message _will be
dropped_ by default.
Prior to 2.7.0 the client wouldn't even attempt to auto-create the queue so it
was possible for messages to essentially be lost (i.e. sent to the broker
"successfully" but dropped).
If you want to keep your existing semantics you just need to use a JMS topic &
multicast, e.g.:
{code:java}
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://localhost:61616");
JmsTemplate jmsTemplate = new JmsTemplate(connectionFactory);
jmsTemplate.setDefaultDestination(new ActiveMQTopic("myAddress")); // use a JMS
topic
jmsTemplate.send(msg -> {
TextMessage textMessage = msg.createTextMessage("body-content-text");
textMessage.setStringProperty("foo", "3");
return textMessage;
});{code}
{code:xml}
{code}
It's worth noting that have multiple _anycast_ queues on an address is rather
uncommon. In your case the only reason it's working is because all the filters
are mutually exclusive. I would definitely recommend using a JMS topic and
multicast configuration as it actually fits your use-case.
Also, I recommend you keep your broker more up-to-date. This change was
introduced over 4 years ago now.
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-4416:
---
Assignee: Justin Bertram
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Assignee: Justin Bertram
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4416.
-
Resolution: Information Provided
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4423) Upgrade Netty to 4.1.97.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated ARTEMIS-4423: --- Summary: Upgrade Netty to 4.1.97.Final (was: Upgrade Netty to 4.1.96.Final) > Upgrade Netty to 4.1.97.Final > - > > Key: ARTEMIS-4423 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4423 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Assignee: Justin Bertram >Priority: Major > Fix For: 2.30.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4423) Upgrade Netty to 4.1.96.Final
Emmanuel Hugonnet created ARTEMIS-4423: -- Summary: Upgrade Netty to 4.1.96.Final Key: ARTEMIS-4423 URL: https://issues.apache.org/jira/browse/ARTEMIS-4423 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Emmanuel Hugonnet Assignee: Justin Bertram Fix For: 2.30.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762767#comment-17762767
]
Damien Picard edited comment on ARTEMIS-4416 at 9/7/23 2:41 PM:
In this file
[ActiveMQSession.java|https://github.com/apache/activemq-artemis/blob/91debf25dbf0f3924d511ee615c6f9b0545e2a5f/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQSession.java#L413C12-L440C14],
_checkDestination_ function:
{code:java}
// Second we create the queue, the address would have existed or
successfully created.
if (destination.isQueue()) {
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination, RoutingType.ANYCAST,
address, null, addressQuery);
} else {
createQueue(destination, RoutingType.ANYCAST, address,
null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} else if (CompositeAddress.isFullyQualified(address)) { // it
could be a topic using FQQN
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination,
RoutingType.MULTICAST, address, null, addressQuery);
} else {
createQueue(destination, RoutingType.MULTICAST,
address, null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} {code}
When we don't use a fully qualified address (FQQN), I don't understand why the
client needs to check if the queue exists. It's the server's responsibility to
forward the message to the correct queue, if the queue doesn't exist, it will
send the message to DLQ or elsewhere.
was (Author: JIRAUSER302079):
In this file
[ActiveMQSession.java|https://github.com/apache/activemq-artemis/blob/91debf25dbf0f3924d511ee615c6f9b0545e2a5f/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQSession.java#L413C12-L440C14],
_checkDestination_ function:
{code:java}
// Second we create the queue, the address would have existed or
successfully created.
if (destination.isQueue()) {
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination, RoutingType.ANYCAST,
address, null, addressQuery);
} else {
createQueue(destination, RoutingType.ANYCAST, address,
null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} else if (CompositeAddress.isFullyQualified(address)) { // it
could be a topic using FQQN
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination,
RoutingType.MULTICAST, address, null, addressQuery);
} else {
createQueue(destination, RoutingType.MULTICAST,
address, null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} {code}
When we don't use a fully qualified address (FQQN), I don't understand why the
client needs to check if the queue exists. It's the server's responsibility to
forward the message to the correct queue, if the queue doesn't exist, it will
[jira] [Commented] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762767#comment-17762767
]
Damien Picard commented on ARTEMIS-4416:
In this file
[ActiveMQSession.java|https://github.com/apache/activemq-artemis/blob/91debf25dbf0f3924d511ee615c6f9b0545e2a5f/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQSession.java#L413C12-L440C14],
_checkDestination_ function:
{code:java}
// Second we create the queue, the address would have existed or
successfully created.
if (destination.isQueue()) {
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination, RoutingType.ANYCAST,
address, null, addressQuery);
} else {
createQueue(destination, RoutingType.ANYCAST, address,
null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} else if (CompositeAddress.isFullyQualified(address)) { // it
could be a topic using FQQN
ClientSession.QueueQuery queueQuery =
session.queueQuery(address);
if (!queueQuery.isExists()) {
if (addressQuery.isAutoCreateQueues()) {
if (destination.isTemporary()) {
createTemporaryQueue(destination,
RoutingType.MULTICAST, address, null, addressQuery);
} else {
createQueue(destination, RoutingType.MULTICAST,
address, null, true, true, addressQuery);
}
} else {
throw new InvalidDestinationException("Destination " +
address + " does not exist, address exists but autoCreateQueues=" +
addressQuery.isAutoCreateQueues());
}
}
} {code}
When we don't use a fully qualified address (FQQN), I don't understand why the
client needs to check if the queue exists. It's the server's responsibility to
forward the message to the correct queue, if the queue doesn't exist, it will
send the message to DLQ or elsewhere.
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4418. - Fix Version/s: 2.31.0 Resolution: Fixed > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.31.0 > > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762763#comment-17762763 ] ASF subversion and git services commented on ARTEMIS-4418: -- Commit 91debf25dbf0f3924d511ee615c6f9b0545e2a5f in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=91debf25db ] ARTEMIS-4418 use consumer delivery sequence in messageId for openwire broker sequence id, makes delivery count calculation independent of message order > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9306) Make the WebConsole accessible from outside the Docker container
[ https://issues.apache.org/jira/browse/AMQ-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762693#comment-17762693 ] Nicolas Filotto commented on AMQ-9306: -- A potential fix https://github.com/apache/activemq/pull/1049 > Make the WebConsole accessible from outside the Docker container > > > Key: AMQ-9306 > URL: https://issues.apache.org/jira/browse/AMQ-9306 > Project: ActiveMQ > Issue Type: Task >Reporter: Nicolas Filotto >Priority: Minor > > Due to AMQ-7007, the WebConsole is not accessible from outside a Docker > container so even if a port is opened on the host to access the WebConsole, > an empty response is returned whatever the HTTP request sent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9306) Make the WebConsole accessible from outside the Docker container
Nicolas Filotto created AMQ-9306: Summary: Make the WebConsole accessible from outside the Docker container Key: AMQ-9306 URL: https://issues.apache.org/jira/browse/AMQ-9306 Project: ActiveMQ Issue Type: Task Reporter: Nicolas Filotto Due to AMQ-7007, the WebConsole is not accessible from outside a Docker container so even if a port is opened on the host to access the WebConsole, an empty response is returned whatever the HTTP request sent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9305) Adapt the docker-related files to Java 17
[ https://issues.apache.org/jira/browse/AMQ-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated AMQ-9305: - Priority: Minor (was: Major) > Adapt the docker-related files to Java 17 > - > > Key: AMQ-9305 > URL: https://issues.apache.org/jira/browse/AMQ-9305 > Project: ActiveMQ > Issue Type: Task >Reporter: Nicolas Filotto >Priority: Minor > > The Dockerfile and corresponding README need to be adapted to Java 17 in > order to be able to launch a snapshot of ActiveMQ 5.19 inside a docker > container. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762686#comment-17762686 ] Gary Tully commented on ARTEMIS-4418: - PR: https://github.com/apache/activemq-artemis/pull/4606 > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9305) Adapt the docker-related files to Java 17
[ https://issues.apache.org/jira/browse/AMQ-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762687#comment-17762687 ] Nicolas Filotto commented on AMQ-9305: -- A potential fix https://github.com/apache/activemq/pull/1048 > Adapt the docker-related files to Java 17 > - > > Key: AMQ-9305 > URL: https://issues.apache.org/jira/browse/AMQ-9305 > Project: ActiveMQ > Issue Type: Task >Reporter: Nicolas Filotto >Priority: Major > > The Dockerfile and corresponding README need to be adapted to Java 17 in > order to be able to launch a snapshot of ActiveMQ 5.19 inside a docker > container. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762685#comment-17762685 ] Gary Tully commented on ARTEMIS-4418: - for reference, the lastDeliveredSequenceId being used on the client: https://github.com/apache/activemq/blob/fc13d61714c1554433fd06becceed55dbe9ef8e5/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L932 > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9305) Adapt the docker-related files to Java 17
[ https://issues.apache.org/jira/browse/AMQ-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated AMQ-9305: - Summary: Adapt the docker-related files to Java 17 (was: Adapt the docker image to Java 17) > Adapt the docker-related files to Java 17 > - > > Key: AMQ-9305 > URL: https://issues.apache.org/jira/browse/AMQ-9305 > Project: ActiveMQ > Issue Type: Task >Reporter: Nicolas Filotto >Priority: Major > > The Dockerfile and corresponding README need to be adapted to Java 17 in > order to be able to launch a snapshot of ActiveMQ 5.19 inside a docker > container. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9305) Adapt the docker image to Java 17
Nicolas Filotto created AMQ-9305: Summary: Adapt the docker image to Java 17 Key: AMQ-9305 URL: https://issues.apache.org/jira/browse/AMQ-9305 Project: ActiveMQ Issue Type: Task Reporter: Nicolas Filotto The Dockerfile and corresponding README need to be adapted to Java 17 in order to be able to launch a snapshot of ActiveMQ 5.19 inside a docker container. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4422) High container memory usage per address size
[ https://issues.apache.org/jira/browse/ARTEMIS-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Månsson updated ARTEMIS-4422: Environment: EKS bottlerocket containerd EC2 nodes. amazoncorretto:17 image (Java 17 JRE) Artemis 2.30.0 2 node cluster, with one node having producers and consumers and the other acting as fail over persistance disabled was: EKS bottlerocket containerd EC2 nodes. amazoncorretto:17 image (Java 17 JRE) Artemis 2.30.0 > High container memory usage per address size > > > Key: ARTEMIS-4422 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4422 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 > Environment: EKS bottlerocket containerd EC2 nodes. > amazoncorretto:17 image (Java 17 JRE) > Artemis 2.30.0 > 2 node cluster, with one node having producers and consumers and the other > acting as fail over > persistance disabled >Reporter: Tobias Månsson >Priority: Major > > We are running a 2 instance clustered Artemis setup, were just one instance > has producers and consumers and the other is a fail over. It's running on EKS > bottlerocket nodes (containerd runtime), in a Java 17 JRE environment. > We've had issues with high memory usage for our Artemis broker for a long > time, but yesterday several events raised a possible candidate to the cause. > We had sudden drops in address size correlating to container memory drops, > and calculations show that each "address size" byte takes 40- 160 "container" > bytes. > Is this normal and intended? > Should the parameter max-size-bytes be multiplied by say 100 to get > "actually" container memory usage? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4422) High container memory usage per address size
[ https://issues.apache.org/jira/browse/ARTEMIS-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Månsson updated ARTEMIS-4422: Priority: Critical (was: Major) > High container memory usage per address size > > > Key: ARTEMIS-4422 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4422 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 > Environment: EKS bottlerocket containerd EC2 nodes. > amazoncorretto:17 image (Java 17 JRE) > Artemis 2.30.0 > 2 node cluster, with one node having producers and consumers and the other > acting as fail over > persistance disabled >Reporter: Tobias Månsson >Priority: Critical > > We've had issues with high memory usage for our Artemis broker for a long > time, but yesterday several events raised a possible candidate to the cause. > We had sudden drops in address size correlating to container memory drops, > and calculations show that each "address size" byte takes 40- 160 "container" > bytes. > Is this normal and intended? > Should the parameter max-size-bytes be multiplied by say 100 to get > "actually" container memory usage? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4422) High container memory usage per address size
[ https://issues.apache.org/jira/browse/ARTEMIS-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Månsson updated ARTEMIS-4422: Description: We've had issues with high memory usage for our Artemis broker for a long time, but yesterday several events raised a possible candidate to the cause. We had sudden drops in address size correlating to container memory drops, and calculations show that each "address size" byte takes 40- 160 "container" bytes. Is this normal and intended? Should the parameter max-size-bytes be multiplied by say 100 to get "actually" container memory usage? was: We are running a 2 instance clustered Artemis setup, were just one instance has producers and consumers and the other is a fail over. It's running on EKS bottlerocket nodes (containerd runtime), in a Java 17 JRE environment. We've had issues with high memory usage for our Artemis broker for a long time, but yesterday several events raised a possible candidate to the cause. We had sudden drops in address size correlating to container memory drops, and calculations show that each "address size" byte takes 40- 160 "container" bytes. Is this normal and intended? Should the parameter max-size-bytes be multiplied by say 100 to get "actually" container memory usage? > High container memory usage per address size > > > Key: ARTEMIS-4422 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4422 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 > Environment: EKS bottlerocket containerd EC2 nodes. > amazoncorretto:17 image (Java 17 JRE) > Artemis 2.30.0 > 2 node cluster, with one node having producers and consumers and the other > acting as fail over > persistance disabled >Reporter: Tobias Månsson >Priority: Major > > We've had issues with high memory usage for our Artemis broker for a long > time, but yesterday several events raised a possible candidate to the cause. > We had sudden drops in address size correlating to container memory drops, > and calculations show that each "address size" byte takes 40- 160 "container" > bytes. > Is this normal and intended? > Should the parameter max-size-bytes be multiplied by say 100 to get > "actually" container memory usage? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4422) High container memory usage per address size
Tobias Månsson created ARTEMIS-4422: --- Summary: High container memory usage per address size Key: ARTEMIS-4422 URL: https://issues.apache.org/jira/browse/ARTEMIS-4422 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.30.0 Environment: EKS bottlerocket containerd EC2 nodes. amazoncorretto:17 image (Java 17 JRE) Artemis 2.30.0 Reporter: Tobias Månsson We are running a 2 instance clustered Artemis setup, were just one instance has producers and consumers and the other is a fail over. It's running on EKS bottlerocket nodes (containerd runtime), in a Java 17 JRE environment. We've had issues with high memory usage for our Artemis broker for a long time, but yesterday several events raised a possible candidate to the cause. We had sudden drops in address size correlating to container memory drops, and calculations show that each "address size" byte takes 40- 160 "container" bytes. Is this normal and intended? Should the parameter max-size-bytes be multiplied by say 100 to get "actually" container memory usage? -- This message was sent by Atlassian Jira (v8.20.10#820010)
