-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Split producer goroutines into sub-structs #300
Labels
Comments
This was referenced Feb 24, 2015
Closed
eapache
added a commit
that referenced
this issue
Jul 7, 2015
- rename topicDispatcher to dispatcher - make a topicProducer struct to handle the old partitionDispatcher - make a partitionProducer struct to handle the old leaderDispatcher - move and rename methods for a much more readable structure Part 1 of #300.
eapache
added a commit
that referenced
this issue
Jul 7, 2015
- rename topicDispatcher to dispatcher - make a topicProducer struct to handle the old partitionDispatcher - make a partitionProducer struct to handle the old leaderDispatcher - move and rename methods for a much more readable structure Part 1 of #300.
eapache
added a commit
that referenced
this issue
Aug 13, 2015
Another chunk of #300. Once this lands the final step will be to break out the existing massive `run()` methods into useful helper functions now that parameter-passing isn't such a pain. In theory no functional changes; just slightly nicer code and stricter typing around channel direction.
eapache
added a commit
that referenced
this issue
Aug 13, 2015
aaronkavlie-wf
pushed a commit
to aaronkavlie-wf/sarama
that referenced
this issue
Aug 18, 2015
Another chunk of IBM#300. Once this lands the final step will be to break out the existing massive `run()` methods into useful helper functions now that parameter-passing isn't such a pain. In theory no functional changes; just slightly nicer code and stricter typing around channel direction.
aaronkavlie-wf
pushed a commit
to aaronkavlie-wf/sarama
that referenced
this issue
Aug 18, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I wrote the producer, I kept each of the five pipeline goroutines as methods on the main
Producer
object for simplicity's sake, however several of them (in particular theflusher
andleaderDispatcher
) have now grown too large. The problem with this choice is that it makes it difficult to split logical chunks of that code out into helper functions, because the helpers cannot modify state in the parent function without some complicated parameter/return value passing.My current thoughts around the fix for #294 are going to make this problem even worse, so before we tackle that we should do a small refactor (internal only, no API changes) of the producer to look more like the current consumer layout: small substructs which contain state variables, thus allowing the large goroutines to be broken up into helper functions and make the code flow much more obvious. Nobody likes reading 150-line functions.
Current thoughts include:
renameCreate struct to manage thebrokerWorker
and use itmessageAggregator
andflusher
goroutinesleaderDispatcher
goroutinesflusher
andleaderDispatcher
to make their main loops more understandable@drdee @yagnik this is a good project for learning more go and getting your hands dirty with the producer design, with very low risk since there should be no functional changes, just code reorg.
The text was updated successfully, but these errors were encountered: