[ 
https://issues.apache.org/jira/browse/ARTEMIS-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Liviu Citu updated ARTEMIS-5189:
--------------------------------
    Description: 
Hi,

We are currently migrating from Classic Broker to Artemis Broker and we also 
want to enable the Failover (Shared-Stored) switch.

We have configured Artemis with Failover (Shared-Store) and during the failover 
switch, topic consumers loose events before reconnecting.

When using durable consumers this is not happening so the problem (as expected) 
is only replicable for non-durable consumers.

 

The reason for which we want to avoid using durable consumer is the performance 
impact on the broker side when there is a big number of messages and consumers 
for it.

For a live client using Classic Broker  we observed a big impact and slowlyness 
of the broker under high load (with more tha 300 durable consumers).

Indeed we are not able to test the same with rtemis Broker as we have no access 
to that environment however our expectation is that the Artemis broker will 
behave similarly.

 

Is there a parameter in Artemis broker to make it wait a bit after the switch 
before dropping topic message, so that previous active consumers  to have time 
to reconnect and consume the messages?

Attached the Artemis Brokers Primary/Backup configuration.

Thank you,

Liviu

  was:
Hi,

I have configured Artemis with Failover (Shared-Store) and during the failover 
switch, topic consumers loose events before reconnecting.

When using durable consumers this is not happening however we would like to use 
non-durable consumers as there is a high workload on the broker (a lot of 
consumers/producers) and it will slow down significantly the message processing 
on the broker side.

Actually initially we were using durable consumers but we have to remove them 
because of performance impact.

Is there a parameter in Artemis broker to make it wait a bit after the switch 
before dropping topic message, so that previous active consumers  to have time 
to reconnect and consume the messages?

Attached the Artemis Brokers Primary/Backup configuration.

Thank you,

Liviu


> [Artemis Failover] [Topics] [Non-Durable Consumers] Lost messages during 
> failover switch
> ----------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-5189
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-5189
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.38.0
>            Reporter: Liviu Citu
>            Priority: Critical
>         Attachments: broker_backup.xml, broker_primary.xml
>
>
> Hi,
> We are currently migrating from Classic Broker to Artemis Broker and we also 
> want to enable the Failover (Shared-Stored) switch.
> We have configured Artemis with Failover (Shared-Store) and during the 
> failover switch, topic consumers loose events before reconnecting.
> When using durable consumers this is not happening so the problem (as 
> expected) is only replicable for non-durable consumers.
>  
> The reason for which we want to avoid using durable consumer is the 
> performance impact on the broker side when there is a big number of messages 
> and consumers for it.
> For a live client using Classic Broker  we observed a big impact and 
> slowlyness of the broker under high load (with more tha 300 durable 
> consumers).
> Indeed we are not able to test the same with rtemis Broker as we have no 
> access to that environment however our expectation is that the Artemis broker 
> will behave similarly.
>  
> Is there a parameter in Artemis broker to make it wait a bit after the switch 
> before dropping topic message, so that previous active consumers  to have 
> time to reconnect and consume the messages?
> Attached the Artemis Brokers Primary/Backup configuration.
> Thank you,
> Liviu



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact


Reply via email to