t;> the producers at the time the failure was triggered.
> >>
> >> We are looking forward to run the tests using a bare metal system in
> order
> >> to eliminate VirtualBox VM from the picture.
> >>
> >> Thanks,
> >> Anindya Haldar
> &
ng a bare metal system in order
>> to eliminate VirtualBox VM from the picture.
>>
>> Thanks,
>> Anindya Haldar
>>
>> Oracle Marking Cloud
>>
>> -Original Message-
>> From: Justin Bertram [mailto:jbert...@apache.org]
>>
Bertram [mailto:jbert...@apache.org]
> Sent: Wednesday, February 14, 2018 6:58 AM
> To: users@activemq.apache.org
> Subject: Re: Artemis 2.4.0 message loss in durability tests upon system
> power-off
>
> The "messages added" metric for a queue is volatile so when the broker is
&
VirtualBox VM from the picture.
Thanks,
Anindya Haldar
Oracle Marking Cloud
-Original Message-
From: Justin Bertram [mailto:jbert...@apache.org]
Sent: Wednesday, February 14, 2018 6:58 AM
To: users@activemq.apache.org
Subject: Re: Artemis 2.4.0 message loss in durability tests upon system
message loss in durability tests upon system
power-off
Hi Anindya,
I would be very surprised if messages were lost due to an ActiveMQ Artemis
broker issue. We have a lot of very extensive testing around these exact use
cases. Could you please check a couple of things:
1. Can you confirm
The "messages added" metric for a queue is volatile so when the broker is
stopped it will be reset. When the broker is started again the "messages
added" will be 0. In your test you say the broker is "powered off" and
then you "resume" the broker. What exactly does this mean? It seems clear
Hi Anindya,
I would be very surprised if messages were lost due to an ActiveMQ Artemis
broker issue. We have a lot of very extensive testing around these exact
use cases. Could you please check a couple of things:
1. Can you confirm that the same guarantees for disk sync apply to a host
VM as
