Skip to content
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 our own threading stuff. #2

Merged
merged 2 commits into from Sep 24, 2014
Merged

Remove our own threading stuff. #2

merged 2 commits into from Sep 24, 2014

Conversation

ralphbean
Copy link
Contributor

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.

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.
@pypingou
Copy link
Member

Nice :) 👍

ralphbean added a commit that referenced this pull request Sep 24, 2014
@ralphbean ralphbean merged commit 90727a2 into develop Sep 24, 2014
@ralphbean ralphbean deleted the feature/de-threaded branch September 24, 2014 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants