-
Notifications
You must be signed in to change notification settings - Fork 3
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
PCIP-3 Pulsar Extended Transaction API Enhancement Proposal #11
Conversation
I think that it is definitively worth to push this initiative to the main repo |
I understand your point that the initiative aims to address an existing bug in Pulsar, which indeed warrants consideration for integration into the main repository. However, modifying the public API in the Pulsar main repository is a challenging and lengthy process, and we cannot guarantee that the new API will be flawless and not require further modifications. Therefore, it makes sense to first iterate on the contributor repository, allowing some users to adopt it and solve their issues before considering a merge into the main repository. |
The CI is failed. |
Change the format of the title. Do you need to change it to: [improve][pcip] PCIP-3 Pulsar Extended Transaction API Enhancement Proposal |
LGTM |
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.
+1 to keep this here for now
Motivation
The motivation behind this proposal is to address the issue of duplicate message consumption when using Fail-over subscription mode with cumulative Ack in Pulsar. Despite the use of transactions, achieving exactly-once semantics has been problematic due to the inherent behavior of cumulative Ack. This issue is particularly challenging to resolve within the constraints of the Pulsar main repository for several reasons:
abort()
andcommit()
appearing synchronous but functioning asynchronously. This leads to incorrect usage patterns, such as needing to callabort().get()
andcommit().get()
for proper operation.Modifications
The proposed solution involves designing a new transaction API in the contributor repository that wraps the original Transaction API. This approach offers several benefits:
Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)