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

feat: idsse-897: minor Publisher refactor #88

Merged
merged 6 commits into from
Dec 4, 2024

Conversation

mackenzie-grimes-noaa
Copy link
Contributor

@mackenzie-grimes-noaa mackenzie-grimes-noaa commented Dec 2, 2024

Linear Issue

IDSSE-897

Changes

Shorter interim PR so the soon-to-exist rabbitmq_utils.Rpc class can reuse as much Publisher logic as possible.

  • Move some Publisher internal methods out into module-wide rabbitmq_utils functions
  • Default Consumer num_message_handlers to 2.
    • We are usually passing 2 in actual usages of the Consumer class, because the caller doesn't usually care or know any better.
  • Bug fix: Publisher and Consumer avoid attempting to declare or bind the default RabbitMQ exchange or queue
    • Previously if you tried to instantiate a Publisher or Consumer passing the default exchange/queue, as RPC Direct Reply-to does, RabbitMQ would throw a fatal error.

Explanation

N/A

@mackenzie-grimes-noaa mackenzie-grimes-noaa marked this pull request as ready for review December 2, 2024 20:23
@mackenzie-grimes-noaa
Copy link
Contributor Author

@Geary-Layne this is 1 of 2 PRs that just moves the publishing logic from Publisher out into a reusable function.

My second PR will have an Rpc class that uses a Consumer + these publisher functions to get around the RabbitMQ constraints of needing to use the same connection/channel to do RPC over the Direct Reply-to queue.

Geary-Layne
Geary-Layne previously approved these changes Dec 3, 2024
Copy link
Contributor

@Geary-Layne Geary-Layne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I would like the 'private' functions to be moved to the bottom of the module, to fallow the convention of having the most relevant code for future users at the top.

@@ -23,6 +24,7 @@

from pika import BasicProperties, ConnectionParameters, PlainCredentials
from pika.adapters import BlockingConnection
from pika.adapters.blocking_connection import BlockingChannel
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be importing (and using) both BlockingChannel and Channel from pika?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we wanted to cover our bases with type hinting, yes, technically all of the functions in rabbitmq_utils that take BlockingChannel args should also work with a generic Channel.

We only use BlockingConnections in rabbitmq_utils though, so all the channels created in this module with connection.channel() will be specifically BlockingChannels.

if isinstance(rmq_params_and_callbacks, list):
self._rmq_params_and_callbacks = rmq_params_and_callbacks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you drop the 'self.' because there is no need to store after initializing the instants, or is there another reason for the change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I just realized this wasn't used anywhere else in the class besides __init__.

Geary-Layne and others added 2 commits December 3, 2024 10:50
I found a bug that I thought I'd fix in your PR. Setting prefetch_count must be done before calling basic_consume.
@mackenzie-grimes-noaa
Copy link
Contributor Author

I would like the 'private' functions to be moved to the bottom of the module, to fallow the convention of having the most relevant code for future users at the top.

Should the classes (Consumer and Producer) be at the top, then public functions, then private functions? As it stands it's organized as

  1. public functions
  2. private functions
  3. classes

@Geary-Layne
Copy link
Contributor

I would definitely have private at the bottom, and have the most relevant to the module at the top. For rabbitmq_utils I think the classes are the most important. I'd have the helper classes first, then Consumer/Publisher/Rpc, then public threadsafe_, and last the private. I believe after RPC is added we won't need subscribe_to_queue and more, but maybe something will still need it.

@mackenzie-grimes-noaa
Copy link
Contributor Author

I would definitely have private at the bottom, and have the most relevant to the module at the top.

Ok, I followed your suggested order now.

  1. NamedTuple data classes
  2. Classes (Consumer, Publisher)
  3. Public functions (subscribe_to_queue, threadsafe_ack, etc.)
  4. Private functions (_setup_exch, _publish, etc.)

@mackenzie-grimes-noaa mackenzie-grimes-noaa merged commit 52172d7 into main Dec 4, 2024
2 checks passed
@mackenzie-grimes-noaa mackenzie-grimes-noaa deleted the feat/idsse-897/publisher-refactor branch December 4, 2024 21:18
Geary-Layne added a commit that referenced this pull request Dec 5, 2024
* add protections for Publisher/Consumer using default exch or queue
* setting prefetch_count must be done before calling basic_consume
* re-order rabbitmq_utils classes and functions
---------

Co-authored-by: Geary Layne <[email protected]>
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.

2 participants