-
Notifications
You must be signed in to change notification settings - Fork 0
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
CV2-5589 More support for queuing under threaded environments #121
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thread local sqs objects should hopefully do it! 🙏
lib/queue/queue.py
Outdated
attributes = {} | ||
if queue_name.endswith('.fifo'): | ||
attributes['FifoQueue'] = 'true' | ||
attributes['ContentBasedDeduplication'] = 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is attributes['ContentBasedDeduplication'] related to the queue ending in .fifo or is it something we want all the time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its a fifo thing - and I realized I copypasta'd here twice so removing one of these!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right; the deduplication is an aspect of how FIFO queues work (where you avoid processing the same message more than once). I don't think we'll ever have a scenario with FIFO, but without deduplication, but it doesn't seem unreasonable to separate these aspects.
""" | ||
Send a message to a specific queue. | ||
""" | ||
queue = self.get_or_create_queue(queue_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to look up the queue each time we send a message? I would have hoped we could store a reference after looking it up once
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that if we do store it we introduce a bunch of state which causes our problem in the first place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first call it will create the resource object, but then it will return a thread local reference on every subsequent request (within that thread). I think this is necessary due to the context switching that could happen otherwise...
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Description
Responding to more issues where we fail to pickup queues under threaded environments. More work to make it threadsafe
Reference: CV2-5589
How has this been tested?
Tested locally and continues to work!
Are there any external dependencies?
No change
Have you considered secure coding practices when writing this code?
No Change