-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[feature][transaction] Add a configuration to control max active transaction of coordinator #15157
Conversation
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.
LGTM!
LGTM :) |
…_active_transaction_limitation
The pr had no activity for 30 days, mark with Stale label. |
…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
…_active_transaction_limitation
...src/main/java/org/apache/pulsar/transaction/coordinator/impl/MLTransactionMetadataStore.java
Show resolved
Hide resolved
@@ -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." |
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.
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 |
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.
# The max active transactions per transaction coordinator | |
# The max active transactions per transaction coordinator, default value 0 indicates no limit. |
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.
LGTM
detail in #15133
Motivation
Currently, the transaction coordinator does not limit the number of active transactions, which may cause the following problems:
Implementation
Add config
add maxActiveTransactions into broker.conf
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:
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:
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
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: