Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Back when it was first written, I realized that bugzilla2fedmsg was going
to need more time than most consumers to do what it needed to do. It
needed to receive a message, then make a costly xmlrpc call to bugzilla
itself to get all kinds of details about the message (history, etc), then
it would pack all that stuff inside the message and forward it along to the
fedora infrastructure bus.
To accomplish this, I wrote some threading stuff into bugzilla2fedmsg. A
master thread would receive messages and put them in a queue. Workers
(each a thread) would take messages off the queue, do their thing, and then
return to wait on the queue.
It worked so well that it was added to fedmsg/moksha core. Now FMN,
fedbadges, and all their friends benefit from this setup.
The time has come to remove bugzilla2fedmsg's own threading machinery. As
it stands now, fedmsg itself spins up a couple threads for the
bugzilla2fedmsg consumer. And then each of those consumer-worker-threads
spins up a couple of their own worker threads! There's no need for that
second layer. This commit removes that.