Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Closed

Conversation

AdamKatzDev
Copy link
Contributor

Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #49023
License MIT

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.

@carsonbot
Copy link

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:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.3 branch.

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!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@AdamKatzDev AdamKatzDev marked this pull request as draft January 18, 2023 18:40
@AdamKatzDev AdamKatzDev marked this pull request as ready for review January 19, 2023 12:46
@carsonbot
Copy link

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:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.3 branch.

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!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@AdamKatzDev AdamKatzDev marked this pull request as draft January 19, 2023 13:05
@AdamKatzDev AdamKatzDev marked this pull request as ready for review January 19, 2023 13:39
@carsonbot
Copy link

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:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.3 branch.

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!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@AdamKatzDev
Copy link
Contributor Author

Not sure why the integration test keeps failing, it seems unrelated to the changes I've made.

@AdamKatzDev
Copy link
Contributor Author

Looks like the tests in AppVeyor are a bit flaky, the code between builds is different only in a comment text:
https://ci.appveyor.com/project/fabpot/symfony/builds/45988646 - RedisExtIntegrationTest::testGetAfterReject crashes
https://ci.appveyor.com/project/fabpot/symfony/builds/45989058 - RedisExtIntegrationTest::testLazy crashes

I suppose that the PR is alright. Though it is a bit suspicious that the Connection tests are failing.

@carsonbot
Copy link

Hey!

I think @ostrolucky has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@nicolas-grekas nicolas-grekas changed the title [Messenger] allow Redis transport to claim multiple messages sequenti… [Messenger] allow Redis transport to claim multiple messages sequentially Apr 18, 2023
@nicolas-grekas nicolas-grekas force-pushed the messenger_redis_claim_fix_5.4 branch from 6f92983 to 79ae82d Compare April 18, 2023 10:19
Copy link
Member

@nicolas-grekas nicolas-grekas left a 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(
Copy link
Member

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(
Copy link
Member

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(
Copy link
Member

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(
Copy link
Member

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);
Copy link
Member

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) {
Copy link
Member

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.

@AdamKatzDev
Copy link
Contributor Author

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.

@nicolas-grekas
Copy link
Member

Thanks for the feedback. Let's close, since this doesn't change the behavior but only the internal implementation, isn't it?

@AdamKatzDev
Copy link
Contributor Author

@nicolas-grekas

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants