-
Notifications
You must be signed in to change notification settings - Fork 8
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
Remove the "state" from a PullConsumer #42
Comments
See my response here: #41 (comment). My idea for
We cannot assume anything about the state term value and also how to serialize or persist it. Or even whether user wants to persist the state. With pure OTP |
I think if the |
I'm working on #36 and thinking about #41 and one thing that feels a bit awkward to me is the fact that our
init/1
callback returns astate
term which is then passed in as an argument whenever a message is received.This feels awkward to me because our PullConsumer can start at any point in the message history, and when we start supporting parallel message processing, which version of the state will we pass to the next message? Will we try to merge the returned
state
of the different messages that were running in parallel?I'm thinking that because this consumer might be starting at any point in the stream (including cases like a crash and restart), your application would have to be designed to manage long-lived state somewhere outside the PullConsumer anyway? But, maybe I'm just missing some context about how you plan to use this in the use case that @mkaput and @sswrk are working towards?
The text was updated successfully, but these errors were encountered: