-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] allow Redis transport to claim multiple messages sequentially #49028
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
Conversation
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
Not sure why the integration test keeps failing, it seems unrelated to the changes I've made. |
Looks like the tests in AppVeyor are a bit flaky, the code between builds is different only in a comment text: I suppose that the PR is alright. Though it is a bit suspicious that the Connection tests are failing. |
Hey! I think @ostrolucky has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
6f92983
to
79ae82d
Compare
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.
Thanks for the PR. I rebased and made a few changes to it, please fetch before working on your branch. Here are some comments to help move this forward.
1 => 'consumer-2', // consumer-name | ||
2 => 3600001, // idle | ||
]]); | ||
$redis->expects($this->exactly(2))->method('xpending')->willReturnOnConsecutiveCalls( |
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.
I forgot to replace willReturnOnConsecutiveCalls with the $series trick (see removed code)
->willReturn([]); | ||
|
||
$redis->expects($this->exactly(3))->method('xpending')->willReturnOnConsecutiveCalls( |
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.
here also, willReturnOnConsecutiveCalls should be replaced, PHPUnit deprecated it.
['symfony', 'consumer', ['queue' => '0'], 1, null], // claim and get message redisid-123 | ||
['symfony', 'consumer', ['queue' => '0'], 1, null] // claim and get message redisid-234 | ||
) | ||
->willReturnOnConsecutiveCalls( |
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.
replace
['queue' => [['message' => '{"body":"2","headers":[]}']]] | ||
); | ||
|
||
$redis->expects($this->exactly(2))->method('xpending')->willReturnOnConsecutiveCalls( |
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.
replace
@@ -329,13 +325,13 @@ private function claimOldPendingMessages() | |||
['JUSTID'] | |||
); | |||
|
|||
$this->couldHavePendingMessages = true; | |||
$couldHavePendingMessages = $couldHavePendingMessages || $claimResult || $try < 3 && $this->claimOldPendingMessages(++$try); |
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.
I added the $couldHavePendingMessages ||
part, to account for the variable possibly being set to true on L311, does that make sense?
@@ -308,19 +308,15 @@ private function claimOldPendingMessages() | |||
$claimableIds = []; | |||
foreach ($pendingMessages as $pendingMessage) { |
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.
on L303, we call
$this->connection->xpending($this->stream, $this->group, '-', '+', 1);
Doesn't the 1
means we ask for only one item? Of not, how much iterations can this loop have? If the number is possibly high, do we need to do anything about that?
Sorry if this question is dumb, I'm not into this topic much.
Hi, @nicolas-grekas. Thank you for your time. The original intent of this PR was to be able to claim multiple stale messages for batch workers, but I've realized that this code won't work for that use case. I've described a possible implementation for new claim algorithm here #44400 (comment). But it is also very complicated and introduces a state into the Connection class, so I wasn't confident in the approach. This PR can improve processing of stale messages when batches are not used, but in that case the queue unlikely to have a lot of stale messages to begin with. I guess the PR simplifies some parts of the code a little bit. |
Thanks for the feedback. Let's close, since this doesn't change the behavior but only the internal implementation, isn't it? |
Right. Redis 6.2.0 introduced IDLE parameter to XPENDING and added XAUTOCLAIM command, it looks like these can help to improve the algorithm significantly, fix the issue that I've tried to tackle here and make the transport usable for batch handlers by also partially fixing #44400. I will make another PR if I have some free time. |
Fix for Redis transport, allows to claim multiple messages sequentially.
Before the fix a worker could claim only a single message per
claim_interval
from another consumer. In some cases this could lead to problems like processing delays or messages piling up.