Skip to content
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

[improve][txn] Take first snapshot before persisting the first transactional message #21406

Merged
merged 19 commits into from
Aug 29, 2024

Conversation

liangyepianzhou
Copy link
Contributor

@liangyepianzhou liangyepianzhou commented Oct 20, 2023

Motivation

The decision to write a snapshot before the first transaction message instead of before building the producer, is based on the fact that only the act of writing transactional messages signifies the use of the transaction buffer. Furthermore, it is only appropriate to schedule snapshot updates after this point.
Otherwise, it will add a lot of unnecessary IO read and write operations and increase the delay of topic load.


Scenario

  • 1000 topics under namespace1.
  • Client1 enables transaction and sends transaction messages to topic 1.
  • Client1 sends normal messages to topic 2~500.
  • Client2 disables transaction and sends messages to topic 501~1000.

Internal Behavior

  • Topic 1~500 will start the 500 task to write snapshots into the same system topic, e.g., system topic 1.
  • All the topics (1~1000) will read this system topic 1 when topic loading.

Modifications

This Pull Request aims to resolve the unnecessary write operation. Starting to write snapshots when sending first transaction messages instead of building producer.

Verifying this change

  • Make sure that the change passes the CI checks.

(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:)

  • Added integration tests for end-to-end deployment with large payloads (10MB)
  • Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • The metrics
  • Anything that affects deployment

Documentation

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

Matching PR in forked repository

PR in forked repository:

@github-actions github-actions bot added the doc-not-needed Your PR changes do not impact docs label Oct 20, 2023
@liangyepianzhou liangyepianzhou self-assigned this Oct 20, 2023
@codelipenghui codelipenghui added this to the 3.2.0 milestone Oct 27, 2023
@codelipenghui codelipenghui added category/performance Performance issues fix or improvements area/transaction type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages labels Oct 27, 2023
1. `testWriteSnapshotWhenFirstTxnMessageSend` mainly test what we want to do. -- Take first snapshot when sending first transaction message.
2. `testMessagePublishInOrder` and `testRefCountWhenAppendBufferToTxn` test the message publish as expected. -- in order and no memory leak.
Add cases for sending second transaction message adn send transaction message failed.
@Technoboy- Technoboy- modified the milestones: 3.2.0, 3.3.0 Dec 22, 2023
@coderzc coderzc modified the milestones: 3.3.0, 3.4.0 May 8, 2024
xiangying added 2 commits August 1, 2024 18:50
@liangyepianzhou
Copy link
Contributor Author

I am confusing why it will be released. Could you talk a little bit about its life cycle to help us understand why we need this retain?

I leaved comment here. The thread is switched one more time here

image

@liangyepianzhou
Copy link
Contributor Author

@codelipenghui @poorbarcode This PR has been here for too long. Would you mind taking another look?

@liangyepianzhou liangyepianzhou dismissed codelipenghui’s stale review August 28, 2024 06:10

The comments are addressed.

@liangyepianzhou
Copy link
Contributor Author

/pulsarbot rerun-failure-checks

@liangyepianzhou liangyepianzhou merged commit e2bbb4b into apache:master Aug 29, 2024
50 of 51 checks passed
@liangyepianzhou liangyepianzhou deleted the firstsnapshot branch August 29, 2024 02:58
grssam pushed a commit to grssam/pulsar that referenced this pull request Sep 4, 2024
…ctional message (apache#21406)

### Motivation
The decision to write a snapshot before the first transaction message instead of before building the producer, is based on the fact that only the act of writing transactional messages signifies the use of the transaction buffer. Furthermore, it is only appropriate to schedule snapshot updates after this point.
Otherwise, it will add a lot of unnecessary IO read and write operations and increase the delay of topic load.

---
  **Scenario**
 * 1000 topics under namespace1.
 * Client1 enables transaction and sends transaction messages to topic 1.
 * Client1 sends normal messages to topic 2~500. 
 * Client2 disables transaction and sends messages to topic 501~1000. 
 
 **Internal Behavior**
 * Topic 1~500 will start the 500 task to write snapshots into the same system topic, e.g., system topic 1.
 * All the topics (1~1000) will read this system topic 1 when topic loading.
### Modifications

This Pull Request aims to resolve the unnecessary write operation. Starting to write snapshots when sending first transaction messages instead of building producer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/transaction category/performance Performance issues fix or improvements doc-not-needed Your PR changes do not impact docs type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants