gojek/ziggurat

Support Stream route disabling

krriteshgupta opened this issue · 4 comments

krriteshgupta commented

This will be handy in case of disaster management. Few examples where this would be a helpful feature.
Suppose there are multiple stream routes in an actor .
1.) One of the routes in this actor starts messing up the data and we want to stop that immediately.

2.) One of the routes in the actor which is not business critical ends up doing some heavy data base operation because of which the processing of business critical events gets slow.We should be able to stop consumption of such route for the time being.

Currently there is no way to achieve this without deleting the route from the code.

So, as a user I should be able to control the enablement of a route by toggling on and off a config.

macalimlim commented

so how do you plan to disable this stream route on a running actor? thru nrepl?

theanirudhvyas commented

@macalimlim it need not be in a running service. I think a better implementation can be through config and redeploying the service. WDYT?

mjayprateek commented

One way to provide this function for a running service is through HTTP APIs :

  1. mount defstate stream currently maintains a vector of all KafkaStreams objects constructed using the stream routes configuration. The number of such objects is equal to the number of stream routes configuration in the service.
  2. Instead of maintaining a vector of KafkaStreams objects, we can maintain a map from stream-id or topic-entity to a KafkaStreams object.
  3. When a person calls HTTP POST on https://some-actor.lambda.golabs.io/v1/stream/start?id=booking, the handler will retrieve the KafkaStreams object corresponding to booking from stream defstate and will call .close method on it to stop it.
  4. We can have a similar API to start the stream. In this case, the HTTP handler will have to invoke .start on the KafkaStreams object.

cc: @theanirudhvyas @macalimlim

WickedBrat commented

@theanirudhvyas Upon discussion with the team during the IPM, we discovered that the issue might not require fixing as the issue is quite old and may not reproduce further during production. Is this feature still required, can you please confirm?