-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running actor in different modes #32
Comments
@hogaur Can I pick this up? |
@RajatVaryani Yeah sure, Go ahead. Assigning it to you. |
Sure. What do you have in mind? |
I was thinking to have three optional options passed while starting the app with Ziggurat such as server, worker(consumes from RabbitMQ), stream-worker. Then these options can be passed to ziggurat so that it figures out what states to start. |
That will work. We will also require a config variable right? To control the mode in which the actor runs? We will use the value of that config in ziggurat's main and then pass on to start function? |
Actually, I think config variable approach is better. Yeah, we can go ahead with that. wdyt @theanirudhvyas ? |
What I had in mind was to pass the mode in a command line argument. This way you don't need separate configs for different modes. And the mode in which ziggurat runs is decided by the arguments passed at startup. |
@theanirudhvyas Do we want the users of the library to quickly change the mode the actor runs in? If that is the case then config would be easier. Wdyt? |
Even if you go the config way, you will still have to restart the service after a config change, how would it be easier? |
I had a conversation with @RajatVaryani where we discussed that going with the config approach will not require a change in the way ziggurat applications are deployed. |
@RajatVaryani we should properly analyze as to how each approach will be implemented and what all changes will be required so that we don't make the same mistake in further discussions. |
@theanirudhvyas Then it's clear to ahead with the command line argument approach right? |
@RajatVaryani Yeah. Please go ahead with the command line approach. |
@RajatVaryani yes, command line approach makes sense now. How are you going about implementing it? |
@theanirudhvyas Let me analyze first and then get back to you. I have few questions as well.
|
@RajatVaryani the argument does not have to be mandatory. By default, we can run all 3 procs. The 3 procs are:
Also could you analyse whether the command line options will except a set of procs or only 1 proc? |
@theanirudhvyas As far as my understanding goes, rabbitmq worker is coupled with kafka streams to add retry, dead letter queue capability. Would it be a good design approach to give access to start different procs? (We might start the kafka worker with retry enabled and not pass rabbitmq worker when ziggurat starts). An alternative approach would be to give only http mode, worker mode and default mode. Wdyt? |
@RajatVaryani Kafka-streams would always start with rabbitmq. But that is not true the other way round, where you would only want to run rabbitmq consumers (and not kafka-streams), in the case where we are flushing rabbitmq queues (while rabbit migration for e.g.). HTTP-server can be its own proc. We should also consider that
|
@RajatVaryani could not continue with this, due to some personal responsibilities. So, I will take this up. |
So there are three procs. I was thinking that ping API would be present in HTTP API mode (no breaking change). |
API changes
|
Allow to only run in worker or server mode, as well as current default mode. Also moving actor management APIs from http routes. Advantages
Isolation between different goals of Kafka consumption and HTTP serving
Easier orchestration, as stream upgrade process can be significantly different from HTTP
The text was updated successfully, but these errors were encountered: