Hi Marc- Yep, that approach sounds on target. The async-replication is a successful approach to avoid the side-effects with sync-based replication in messaging systems.
-Matt > On May 22, 2024, at 5:43 PM, Marc Boorshtein <mboorsht...@gmail.com> wrote: > > Thanks Matt for the explanation. We have two scenarios we want to be able > to do: > > 1. In cluster HA - Right now we have one Deployment with a PVC. If the AMQ > dies the client app stops working until the AMQ deployment is back up. > It's not high volume at all. If I hear what you're saying, and have read > the docs properly, then what we should do is have two seperate deployments > both pointing to the same PVC in ReadWriteMany. One (the master) will lock > the kahadb and the other (slave) will wait for the lock to clear. Then in > our clients we configure the URL with failover and both pods (via their > service dns names) to connect to. Then tis just a matter of whichever of > the two pods are accepting connections. Do I have that right? > > 2. Remote cluster forwarding - for specific queues, I want my client to > write the message to the local cluster's AMQ and then forward that message > to a broker in a remote cluster, regardless of if there's an existing > consumer. The idea is that certain operations will be written to the > remote cluster to replicate operations. I want to the reliability of > knowing that my client has sent the message to the local cluster, and the > local cluster will reliably deliver it to the remote cluster, even if that > cluster is not available right now. Is that what i'd use a virtual > destination for? or would I configure the remote AMQ to be a client to the > local AMQ so that it pulls in the message and stores it locally until the > client pulls it in? > > Am I thinking about this correctly? > > Thanks again > Marc
