You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Seckin Pulatkan (Jira)" <ji...@apache.org> on 2021/10/18 09:06:00 UTC
[jira] [Comment Edited] (ARTEMIS-3002) Client failover broken by
"QUEUE_DOES_NOT_EXIST" server error
[ https://issues.apache.org/jira/browse/ARTEMIS-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429889#comment-17429889 ]
Seckin Pulatkan edited comment on ARTEMIS-3002 at 10/18/21, 9:05 AM:
---------------------------------------------------------------------
Hi, I can confirm this issue also on Artemis 2.10.1 client/server and 2.16.0 client/server with Wildfly 18.0.1 and Wildfly 23.0.2.Final with extended version of [Vromero's Artemis docker |https://github.com/vromero/activemq-artemis-docker] 2.10.1-alpine and 2.16.0-alpine
I noticed one thing different though. The consumers with @ActivationConfigProperty : shareSubscriptions=false were able to recreate the queue and consumer connection.
Other consumers (with shareSubscriptions=true and specific subscriptionName) got QUEUE_DOES_NOT_EXIST error on server side.
On client side I saw these warning messages
{noformat}
WARN [org.apache.activemq.artemis.core.client] (Thread-18 (ActiveMQ-client-netty-threads)) AMQ212036: Can not find packet to clear: 2 last received command id first stored command id 0
{noformat}
If I restart wildfly then the queues are created and consumers are connected without an error on server side.
I have tried many combinations on following connection factory but same result
{code:xml}
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:/jms/RemoteArtemisConnectionFactory java:jboss/DefaultJMSConnectionFactory"
connectors="remote-artemis" ha="${env.WILDFLY_ARTEMIS_HA:true}"
reconnect-attempts="-1" retry-interval="1000" retry-interval-multiplier="1.5" max-retry-interval="60000" transaction="xa"
failover-on-initial-connection="true" connection-load-balancing-policy-class-name="org.apache.activemq.artemis.api.core.client.loadbalance.FirstElementConnectionLoadBalancingPolicy"
connection-ttl="30000" client-failure-check-period="15000" use-auto-recovery="true" confirmation-window-size="10000000" />
{code}
ha=true or ha=false, confirmation-window-size=-1 or confirmation-window-size="10000000", etc.
On server side, we have this address-setting (so auto create addresses or queues are set as true)
{code:xml}
<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>20000</redelivery-delay>
<redelivery-delay-multiplier>2</redelivery-delay-multiplier>
<max-redelivery-delay>3600000</max-redelivery-delay>
<max-delivery-attempts>10</max-delivery-attempts>
<auto-create-queues>true</auto-create-queues>
<auto-delete-queues>false</auto-delete-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-delete-addresses>false</auto-delete-addresses>
<default-group-buckets>1024</default-group-buckets>
</address-setting>
{code}
If I stop docker container of Artemis server and start again, then consumers are able to connect as it is considered to be reattachment
If I remove docker container of Artemis server and run another container, only non-shared subscriptions are created and connected. I do not expect a reattachment but I thought client would at least reconnect and re-create the queue and consumer connection. It is only possible if we restart the client application.
There is no issue on message production, at that time address is created and message is put to topic, but since there is no queue (as consumer was not able to create it) the message ends up as un-routed message.
was (Author: seckin.pulatkan):
Hi, I can confirm this issue also on Artemis 2.10.1 client/server and 2.16.0 client/server with Wildfly 18.0.1 and Wildfly 23.0.2.Final with extended version of [Vromero's Artemis docker https://github.com/vromero/activemq-artemis-docker] 2.10.1-alpine and 2.16.0-alpine
I noticed one thing different though. The consumers with @ActivationConfigProperty : shareSubscriptions=false were able to recreate the queue and consumer connection.
Other consumers (with shareSubscriptions=true and specific subscriptionName) got QUEUE_DOES_NOT_EXIST error on server side.
On client side I saw these warning messages
{noformat}
WARN [org.apache.activemq.artemis.core.client] (Thread-18 (ActiveMQ-client-netty-threads)) AMQ212036: Can not find packet to clear: 2 last received command id first stored command id 0
{noformat}
If I restart wildfly then the queues are created and consumers are connected without an error on server side.
I have tried many combinations on following connection factory but same result
{code:xml}
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:/jms/RemoteArtemisConnectionFactory java:jboss/DefaultJMSConnectionFactory"
connectors="remote-artemis" ha="${env.WILDFLY_ARTEMIS_HA:true}"
reconnect-attempts="-1" retry-interval="1000" retry-interval-multiplier="1.5" max-retry-interval="60000" transaction="xa"
failover-on-initial-connection="true" connection-load-balancing-policy-class-name="org.apache.activemq.artemis.api.core.client.loadbalance.FirstElementConnectionLoadBalancingPolicy"
connection-ttl="30000" client-failure-check-period="15000" use-auto-recovery="true" confirmation-window-size="10000000" />
{code}
ha=true or ha=false, confirmation-window-size=-1 or confirmation-window-size="10000000", etc.
On server side, we have this address-setting (so auto create addresses or queues are set as true)
{code:xml}
<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>20000</redelivery-delay>
<redelivery-delay-multiplier>2</redelivery-delay-multiplier>
<max-redelivery-delay>3600000</max-redelivery-delay>
<max-delivery-attempts>10</max-delivery-attempts>
<auto-create-queues>true</auto-create-queues>
<auto-delete-queues>false</auto-delete-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-delete-addresses>false</auto-delete-addresses>
<default-group-buckets>1024</default-group-buckets>
</address-setting>
{code}
If I stop docker container of Artemis server and start again, then consumers are able to connect as it is considered to be reattachment
If I remove docker container of Artemis server and run another container, only non-shared subscriptions are created and connected. I do not expect a reattachment but I thought client would at least reconnect and re-create the queue and consumer connection. It is only possible if we restart the client application.
There is no issue on message production, at that time address is created and message is put to topic, but since there is no queue (as consumer was not able to create it) the message ends up as un-routed message.
> Client failover broken by "QUEUE_DOES_NOT_EXIST" server error
> -------------------------------------------------------------
>
> Key: ARTEMIS-3002
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3002
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.13.0, 2.16.0
> Reporter: Apache Dev
> Priority: Critical
>
> Two brokers using HA with shared storage.
> When active broker is killed, backup broker becomes live and clients try to connect to it.
> Randomly, this can happen:
> * client reconnects successfully
> * broker logs the following exception:
> AMQ224016: Caught exception: ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST message=AMQ229017: Queue XXX does not exist]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createConsumer()
> * client is no more consuming messages
> Really similar to the following issues:
> * https://issues.redhat.com/browse/WFLY-12859
> * https://issues.apache.org/jira/browse/ARTEMIS-1217
> It seems that client, right after reconnection, tries to recreate consumers, but queue bindings have not yet been created on new live server.
> As a workaround it seems to be working to define all queues statically in broker configuration.
> However this is not possible for temporary queues, which also seem to be affected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)