hello everybody, I have a reproducible test case that demonstrate that pulsar 2-way geo replication doesn't support exclusive access producers. If this is a limitation made by design, I am not sure what benefit that could bring. Otherwise, if it's not a limitation made by design, I believe that it should be resolved to strengthen and improve the pulsar geo replication feature. I have opened this issue 24914. Will appreciate if someone can take a look and suggest whether it makes sense or not.

Yes, that's a valid observation that it's a limitation of the current replication design. I guess the replication use case wasn't considered when exclusive mode was added. However since exclusive mode is really meant to be exclusive, replication could break the expectations. Perhaps exclusive producers shouldn't be used when topics are replicated? What's the use case for using exclusive producers in your case?

the use case is a typical enterprise setup where geo replication is part of the more general high availability setup. This user is actually using ExclusiveWithFencing so they are planning for producing from a second cluster if the first cluster stops working.

This user is actually using ExclusiveWithFencing so they are planning for producing from a second cluster if the first cluster stops working.

Do they have the expectation that

ExclusiveWithFencing

would work across geo-replication?

yes, that is the expectation, do you think it's not a safe expectation?

Geo-replication cannot coordinate exclusive access across clusters, at least currently. It's designed more for active-passive scenarios. This applies for exclusive producers and replicated subscription consumers. For example, consuming concurrently on the same replicated subscription is not prevented in Pulsar, but it will result in messages being processed by consumers in either cluster with a lot of duplicate processing. The design of replicated subscriptions is for active-passive scenarios. There's some docs in https://pulsar.apache.org/docs/next/concepts-cluster-level-failover/ and https://pulsar.apache.org/docs/next/client-libraries-cluster-level-failover/ about handling active-passive scenarios (cluster level failover), but the documentation doesn't cover all details.

ok, I see, that is the current philosophy about DR in pulsar, maybe my issue can be used as a discussion point to evaluate if it makes sense to go for an active-active type of approach.

geo-replication is asynchronous replication and loosely coupled. Applications must be designed to take this into account. If it's not possible to make the applications work according to the limitations, the other option for replication is to use a single "stretched cluster" across geographically distributed regions. This is "synchronous geo-replication replication via BookKeeper". That comes with tradeoffs such as additional cost and latency. The documentation about active-active replication is misleading. There's no such support in Pulsar with asynchronous geo-replication with strong consistency. The problem in the diagram is that 2 consumers cannot actively consume on the same subscription without a lot of duplicates being processed by both consuming applications. This would only make sense with Shared subscriptions in cases where duplicate processing isn't an issue.

all right, thanks for this Lari, it is very interesting. I now have a better understanding of the pulsar approach to geo-replication