You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[feature][transaction] Add a configuration to control max active transaction of coordinator (#15157)
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
```makefile
# 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

### 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.
Copy file name to clipboardexpand all lines: pulsar-transaction/coordinator/src/main/java/org/apache/pulsar/transaction/coordinator/TransactionMetadataStoreProvider.java
Copy file name to clipboardexpand all lines: pulsar-transaction/coordinator/src/main/java/org/apache/pulsar/transaction/coordinator/exceptions/CoordinatorException.java
+12
Original file line number
Diff line number
Diff line change
@@ -119,4 +119,16 @@ public TransactionMetadataStoreStateException(TransactionCoordinatorID tcID,
119
119
120
120
}
121
121
}
122
+
123
+
/**
124
+
* Exception is thrown when a operation of new transaction reach the number of max active transactions.
Copy file name to clipboardexpand all lines: pulsar-transaction/coordinator/src/main/java/org/apache/pulsar/transaction/coordinator/impl/InMemTransactionMetadataStoreProvider.java
+2-1
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,8 @@ public CompletableFuture<TransactionMetadataStore> openStore(TransactionCoordina
Copy file name to clipboardexpand all lines: pulsar-transaction/coordinator/src/main/java/org/apache/pulsar/transaction/coordinator/impl/MLTransactionMetadataStore.java
+47-38
Original file line number
Diff line number
Diff line change
@@ -76,18 +76,21 @@ public class MLTransactionMetadataStore
Copy file name to clipboardexpand all lines: pulsar-transaction/coordinator/src/main/java/org/apache/pulsar/transaction/coordinator/impl/MLTransactionMetadataStoreProvider.java
+3-2
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,8 @@ public CompletableFuture<TransactionMetadataStore> openStore(TransactionCoordina
0 commit comments