Do consumers/subscriptions get lost between HTTP bridge restarts? #792
-
Hello all, I've been playing around with deploying HTTP Bridge with Strimzi as an alternative to connecting via the Kafka protocol, and I noticed some behavior I wanted to confirm. It would seem that if the HTTP bridge pod goes down, it loses all the created consumers/subscriptions and they must be recreated. The consumers are created and stored in an in-memory map called and here is the place in the If I'm understanding this correctly, there is nothing in place to repopulate that map if the bridge pods goes down. Does that mean the client applications should have logic for recreating both the consumers and the subscriptions in the case of pod restarts? I didn't find anything in the docs explaining if this was the case either, so I appreciate any insight you can offer! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
That is correct. The consumers and subscriptions are lost when the bridge restarts. That is expected behavior.
I do not know anything about your project - but in general, I think whenever you have a good Kafka client available, you should use it. The HTTP Bridge makes sense in situations when you do not have a Kafka client around or it would need too many resources to use it (e.g. IoT use-cases) or for example when you want to better isolate your Kafka cluster from the outside world (e.g. using HTTP from the remote application over open internet instead of the Kafka protocol.). |
Beta Was this translation helpful? Give feedback.
That is correct. The consumers and subscriptions are lost when the bridge restarts. That is expected behavior.
I do not know anything about your project - but in general, I think whenever you have a good Kafka client available, you should use it. The HTTP Bridge makes sense in situations when you do not have a Kafka client around or it would need too many resources to use it (e.g. IoT use-cases) or for example when you want to better isolate your Kafka cluster from the outside world (e.g. using HTTP from the remote application over open internet instead of the Kafka protocol.).