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

[feature][transaction] Add a configuration to control max active transaction of coordinator #15157

Conversation

congbobo184
Copy link
Contributor

@congbobo184 congbobo184 commented Apr 13, 2022

detail in #15133

  • Status: Discussion
  • Author: Bo Cong
  • Pull Request:
  • Mailing List discussion:
  • Release: 2.11

Motivation

Currently, the transaction coordinator does not limit the number of active transactions, which may cause the following problems:

  • A large number of active transactions will put a lot of pressure on memory
  • The transaction that a single TC can handle is limited, so the active transaction cannot be expanded infinitely
  • End transaction should wait TP or TB recover success, so a lot end request will pending in TP or TB and TC don't kown the state of the TB or TP, it will wast a lot of resource of the machine. If there have a lot of TB or TP request in pending state, it will cause the OOM

Implementation

Add config

add maxActiveTransactions into broker.conf

# The max active transactions in one transaction coordinator
maxActiveTransactionsPerCoordinator=10000

How to handle the number of active transactions reach the maxActiveTransactions?

If reach the maxActiveTransactions, return the Exception to client. It has a lot of disadvantages:

  1. broker should add a ReachMaxActiveTxnException, if reach the max active txn exception. client need try this exception then do op. every client will handle the ReachMaxActiveTxnException.
  2. client receive this transaction will not stop open txn, because it don't know what time the TC will be recoverd. It will retry now. When the TC can't recover, the client will keep retrying. But this op is not make sense.

Design

When this op request reach the maxActiveTransactions, coordinator don't return any response for this request. ignore this request directly. In this way, broker don't need to add any exception for this config.

Let's we can see, how does this way will affect the client?

If broker don't return the reponse for this request, the op of open txn will timeout. and in coordinator client, it has a semaphore to control the op of txn(open, add produce topic, add ack topic, end txn). In the timeout time, the coordinator client only can open the number of semaphore txns. Any other request will be block. So this design slove this two problems:

  1. don't need to add a exception
  2. client will not infinite retry

Worries

If you are worried that this design will affect the client-side experience, because the open transaction will always time out and other txn op will be blocked. I think your worry is superfluous, At this time, you should consider increasing the performance of the cluster or find the problematic client to repair.

flow chart

image

Compatibility, Deprecation, and Migration Plan

maxActiveTransactions default = 0, if maxActiveTransactions will not block open txn

Test Plan

reach maxActiveTransactions client open txn will timeout

Rejected Alternatives

If reach the maxActiveTransactions, return the Exception to client. It has a lot of disadvantages:

  1. broker should add a ReachMaxActiveTxnException, if reach the max active txn exception. client need try this exception then do op. every client will handle the ReachMaxActiveTxnException.
  2. client receive this transaction will not stop open txn, because it don't know what time the TC will be recoverd. It will retry now. When the TC can't recover, the client will keep retrying. But this op is not make sense.

@congbobo184 congbobo184 added area/config area/transaction component/transaction-coordinator doc-complete Your PR changes impact docs and the related docs have been already added. labels Apr 13, 2022
@congbobo184 congbobo184 added this to the 2.11.0 milestone Apr 13, 2022
@congbobo184 congbobo184 self-assigned this Apr 13, 2022
@gaozhangmin gaozhangmin changed the title Congbobo184 add max active transaction limitation [feature][transaction] Add a configuration to control max active transaction of coordinator Apr 13, 2022
@RobertIndie RobertIndie added the type/feature The PR added a new feature or issue requested a new feature label Apr 13, 2022
Copy link
Contributor

@liangyepianzhou liangyepianzhou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@HQebupt
Copy link
Contributor

HQebupt commented Apr 14, 2022

LGTM :)

@github-actions
Copy link

The pr had no activity for 30 days, mark with Stale label.

congbobo184 added 5 commits May 30, 2022 18:43
…itation

# Conflicts:
#	conf/broker.conf
#	pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java
#	site2/docs/reference-configuration.md
…m/BewareMyPower/pulsar into bewaremypower/last-cumulative-ack

# Conflicts:
#	pulsar-client/src/main/java/org/apache/pulsar/client/impl/PersistentAcknowledgmentsGroupingTracker.java
@@ -2592,6 +2592,12 @@ public class ServiceConfiguration implements PulsarConfiguration {
)
private long transactionBufferClientOperationTimeoutInMills = 3000L;

@FieldContext(
category = CATEGORY_TRANSACTION,
doc = "The max active transactions per transaction coordinator."
Copy link
Contributor

@gaoran10 gaoran10 Jun 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
doc = "The max active transactions per transaction coordinator."
doc = "The max active transactions per transaction coordinator, default value 0 indicates no limit."

conf/broker.conf Outdated
@@ -1432,6 +1432,9 @@ transactionBufferSnapshotMinTimeInMillis=5000
# The max concurrent requests for transaction buffer client, default is 1000
transactionBufferClientMaxConcurrentRequests=1000

# The max active transactions per transaction coordinator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# The max active transactions per transaction coordinator
# The max active transactions per transaction coordinator, default value 0 indicates no limit.

Copy link
Contributor

@gaoran10 gaoran10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/config area/transaction doc-complete Your PR changes impact docs and the related docs have been already added. lifecycle/stale type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants