Of course replication will have a cost, but it happens asynchronously.
We replicate the data on the backup before routing messages. It all happens fast and failover would have the data available at the backup server in case of a crash.
We replicate the data on the backup before routing messages.
Thanks, I just to make sure I understand what that means. Are you saying that a client posting a message to a queue will not get a response to the call (e.g. javax.jms.MessageProducer.send(....)) until the message has been successfully replicated to the backup server?
It depends on your sync mode.
If you are sending transactionally... all the sends will be sent asynchronously from the client. But it would wait on commit.
For persistent and non-persistent, it will depend on those settings:
So, basically it all depends on what are your requirements and those settings will adapt to either way you want it.
I've read through the Chapter 21 reference you listed here about "Guarentees of sends and commits" and think I understand that, though there's no direct mention of replication to the backup server, only whether the data gets "persisted to storage".
It would seem that you're implying that replication to the backup server is treated as part of the "persist to storage" step. Is that the case, and if so, what's the behavior if the backup system is unavailable?