Project

General

Profile

Actions

Feature #61532

closed

implement retry expiery mechanism for persistent notifications

Added by Yuval Lifshitz 11 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
Community (user)
Tags:
notifications
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

currently persistent notifications are retried indefinitly.
the only limiting mechanism that exists is that all notifications are stored in one RADOS object (of size 128MB).
assuming notifications are ~1KB, this would give us about 128K notifications that can wait in the queue.
when the queue fill up (e.g. kafka broker is down for 20 minutes, we are sending ~100 notifications per second) we start sending "slow down" replies to the client, and the S3 operation are not performed.
to avoid that we propose several options:
  • use a fifo instead of a queue. this would allow us to hold more than 128K messages, and survive longer broker outages, and at higher message rate. there should still probably be a limit set on the size of the fifo
  • define maximum number of retires allowed for a notification
  • define maximum time the notification may stay in the queue before it is removed

would recommend that these definitions are done as topic attributes, reflecting our delivery guarantees for this spoecific destination.
would recommend that at first this

Actions #1

Updated by Krunal Chheda 11 months ago

was checking on what AWS does, and could not find any official doc listing,
Just some reference where it says it retries 3 times.

Actions #2

Updated by Krunal Chheda 10 months ago

Hi Yuval,
While we still get consensus around retry options/timeout options, we have quorum on at least to change the asyn notification to use cls_Fifo.
So in today's meeting, I proposed that bloomberg can start work on fifo implementation while the other options are being tracked.
Also there was a suggestion to have a fix size for FIFO as well, but there was no value was decided. Again while we decide on the value for FIFO max_size we can start our work on implementing FIFO.
Just putting out here, since you were not there in the meeting. Let me know if any comments.

Actions #3

Updated by Yuval Lifshitz 10 months ago

these are great news!
implementing the queue via FIFO would allow for much larger queue, and may also improve on performance as the FIFO usually utilize 2 OSDs - one for read and one for write.

regarding the question of size. allowing for unlimited FIFO would simplify the implementation of the "2 phase commit (=2pc) queue", as it will not be necessary to reserve and then commit. there will be only "push" to the FIFO, that would fail only if we ran out of space in the pool.
however, it would probably be straight forward to reuse the code of the 2pc_queue in the case of the FIFO.

Actions #4

Updated by Ali Masarwa 9 months ago

I had a discussion with Yuval, we decided on the following:
we will implement a limitation for the retries of persistent topic by:
1. adding a maximum retries for the notification
2. adding an expiry by seconds (retry for max 100 seconds)
3. we want to add retry sleep to control the frequency of the retries (retry every 10 seconds)

we will add these configuration globally and per topic

Actions #5

Updated by Krunal Chheda 9 months ago

Thanks Ali for getting things moving, we were going to bring this up as we (Bloomberg) have started working on this tracker.
So adding both retry and timeout seems meaningful. to configure this will it be part of CreateTopic or rgw config (global value )
Would be nice know so that we can work along

Actions #6

Updated by Ali Masarwa 9 months ago

You are welcome!!
We will do both, one global configured by RGW admin (used in case topic doesn't specify a retry configuration) and another per topic which should override the global configuration.
This is the plan as of now, we are still working on this (and it got delayed a bit because I worked on bug recently that had to be addressed urgently)

Actions #7

Updated by Krunal Chheda 9 months ago

Ali Masarwa wrote:

You are welcome!!
We will do both, one global configured by RGW admin (used in case topic doesn't specify a retry configuration) and another per topic which should override the global configuration.
This is the plan as of now, we are still working on this (and it got delayed a bit because I worked on bug recently that had to be addressed urgently)

hey Ali, some confusion here when you say "we are still working on this", does it mean that you'll are working on finalizing the requirements ? or doing the actual development work ? As per initial meetings, we had volunteered to do dev work for this feature.

Actions #8

Updated by Yuval Lifshitz 7 months ago

  • Status changed from New to Resolved
  • Pull request ID set to 52634

implemented in these 2 PRs:
https://github.com/ceph/ceph/pull/52634
https://github.com/ceph/ceph/pull/52964

the fifo work will be done in a separate PR.
work breakdown could be found here: https://tracker.ceph.com/issues/61532

Actions

Also available in: Atom PDF