As long as the consumer is holding the queue, the message should not
be expired.
Next time it is redelivered (after say a rollback) then the message
will be checked again for expired.
Implementing the semantic you expect would be troublesome. you would
receive the message... hold the ack.. and i
Hi,
In our activemq installation we are using kahaDb as the persistence adapter
with leased-database-locker for locking mechanism. The shared file system
used is NFSv3.
We wanted to test scenario where the Master node has access to mysql through
which it will remain master by acquiring lock but
We are using *ActiveMQ 5.13.4* and *ActiveMQ 5.15.3*
with the below configuration
A producer sends a persisted message on a queue with a TTL of 5 sec.
A consumer consumes a message but without acknowledg
The DiscoveryGroup is used to listen for UDP-multicast broadcasts from a
broker's BroadcastGroup. The connector defined in the broker's
BroadcastGroup is what the client will use to connect to that broker. Of
course, this presents a problem for things that need to be configured
specifically for eac
This looks like a bug to me. Could you describe a simple way to reproduce
the issue?
Justin
On Mon, Apr 30, 2018 at 11:29 AM, Daniel Hutchison wrote:
> Hi,
>
> I've recently upgraded to artemis 2.5 from an old version of activemq.
> I've been running in my test environment for about 2 weeks
I think there is some misunderstanding that I created. We don't plan to use
activemq to populate the cache. We build the cache on cache misses. Here's
how the overall flow looks like. Note there are multiple jvm's involved, I
have just pictured one for simplicity.
I didn't completely follow your r
We are using ActiveMQ 5.13.4 and ActiveMQ 5.15.3
with the below configuration
A producer sends a persisted message on a queue with a TTL of 5 sec.
A consumer consumes a message but without acknowledgin
