Hi
I am using ActiveMQ 5.10 in an application. So far the requirement for the remote locations has been for pure store and forward capabilities,
so that a single AMQ broker was sufficient. This has changed in a way that now 2 nodes should be present in the remote location for
resilience and load balancing. I had considered a master/configuration as the requirement for resilience is stronger than that for load balancing.
However, the situation in those locations is that I don’t have a shared db nor a shared filesystem. As far as I have understood the replicated level db
would require at least 3 nodes ?
This is why I have chosen a network of brokers in the end, which works well for any Queue based communication.
Now my problem is that there is one client application that is provided by a 3rd party and uses durable subscriptions. It would be quite an effort
to change that application towards using queues, so that I could consider virtual destinations.
The problem occurs two-fold:
Assume a Subscriber connects to BrokerA, then disconnects and reconnects to Broker B. It consumes messages for a while, than disconnects
and reconnects to Broker A. All messages that have already been consumed while it was connected to Broker B will be delivered again.
My question is now whether this could be avoided by means of ActiveMQ alone ? - I was contemplating a broker plugin to track messages that
have been consumed on other nodes so that I could avoid redelivering them again.
Sorry if thats a bit vague - I am fishing for ideas ….
Thanks and best regards
Andreas
I am using ActiveMQ 5.10 in an application. So far the requirement for the remote locations has been for pure store and forward capabilities,
so that a single AMQ broker was sufficient. This has changed in a way that now 2 nodes should be present in the remote location for
resilience and load balancing. I had considered a master/configuration as the requirement for resilience is stronger than that for load balancing.
However, the situation in those locations is that I don’t have a shared db nor a shared filesystem. As far as I have understood the replicated level db
would require at least 3 nodes ?
This is why I have chosen a network of brokers in the end, which works well for any Queue based communication.
Now my problem is that there is one client application that is provided by a 3rd party and uses durable subscriptions. It would be quite an effort
to change that application towards using queues, so that I could consider virtual destinations.
The problem occurs two-fold:
Assume a Subscriber connects to BrokerA, then disconnects and reconnects to Broker B. It consumes messages for a while, than disconnects
and reconnects to Broker A. All messages that have already been consumed while it was connected to Broker B will be delivered again.
My question is now whether this could be avoided by means of ActiveMQ alone ? - I was contemplating a broker plugin to track messages that
have been consumed on other nodes so that I could avoid redelivering them again.
Sorry if thats a bit vague - I am fishing for ideas ….
Thanks and best regards
Andreas