GitHub user StormLord07 added a comment to the discussion: Guaranteeing reply delivery to the same instance in KeyShared subscription without per-instance topics
Thanks for the reply. We ended up with a split approach: * gRPC for true request/response. * Pulsar for everything else, like topics w/o replies, stuff that requires reading from multiple services, etc. > For an RPC use case over Pulsar, there's an example at > https://github.com/streamnative/pulsar-recipes/tree/main/rpc. > You'd need to use sticky with Key_shared. We built something similar, though w/o the regex, didn't know it was a thing. It could have worked. But in our way the same issue about collisions of murmur hash persisted, we used the sticky range and key_shared sub > Why do you want to avoid this? Pulsar supports a large number of topic and > subscriptions. Mainly operational risk and startup cost: * Lifecycle/cleanup worst case scenario: service A is restarted daily while service B might restart twice a year. Per-instance topics/subs require robust detection of “no more producers/consumers” to trigger cleanup. Without that, stale topics/subs accumulate in service B, which can trigger too much open files error, and * Resource footprint: Each new producer/consumer initiates broker connections, which takes some time, might not be very big, but we still try to avoid things like that * We missed TTL early on and it's still a pretty big number for it to not delete a good topic, we use per namespace TTL, a day or few, Which doesn't save us from some problems I'll describe in next part > What is the reason for avoiding duplication? Are the messages large? Not really, we’re fine with duplication in pipelines when it’s intentional. Our concern was accidental fan-out during RPC-like flows, which can inflate load with no benefit. In our dev env a small bug created a new topic per request. A smoke test then spawned a very large number of topics. Broker or bookkeeper became overloaded, and CLI tool became useless, throwing Java OOMs, we couldn't delete topics, and TTL was set at a few days, so we had to manually reset. If i remember correctly it was just bookeeper, but might have been full pulsar broker. It was our mistake and a bad design decision overall, but it pushed us toward a design that minimizes blast radius from such bugs. Thanks again for reply, might look into the regex solution in case, but I think we'll stick with gRPC for RPC. since it is what it's build for in a first place. Also I've heard that there is a RPC coming or is it something else [https://deepwiki.com/apache/pulsar-java-contrib/4.1-rpc-system-architecture](https://deepwiki.com/apache/pulsar-java-contrib/4.1-rpc-system-architecture) as far as i understood its a proposal? GitHub link: https://github.com/apache/pulsar/discussions/24616#discussioncomment-14212662 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
