[
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)
