codelipenghui commented on code in PR #22452:
URL: https://github.com/apache/pulsar/pull/22452#discussion_r1558662937
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java:
##########
@@ -3942,9 +3942,13 @@ public void publishTxnMessage(TxnID txnID, ByteBuf
headersAndPayload, PublishCon
@Override
public CompletableFuture<Void> endTxn(TxnID txnID, int txnAction, long
lowWaterMark) {
if (TxnAction.COMMIT_VALUE == txnAction) {
- return transactionBuffer.commitTxn(txnID, lowWaterMark);
+ return transactionBuffer.commitTxn(txnID, lowWaterMark).thenRun(()
-> {
+ lastDataMessagePublishedTimestamp = Clock.systemUTC().millis();
Review Comment:
> Yes, it does. But i think that it is a good tradeoff that we allow wrong
update, because LastDataMessagePublishedTimestamp is used to skip creating
unnecessary subscription replication snapshot.
Updating incorrectly just creating an unnecessary snapshot.
On the contrary, if we chase for strictly correctess, we have to take lots
of effort to determine whether the max read position move forward or not.
But we can't allow missing update, which will skip creating necessary
subscription replication snapshot.
We already have `updateMaxReadPosition(TxnID txnID)` method in
TopicTransactionBuffer.java. And it checked if the maxReadPosition is changed
or not. So we can just allow the topic to register a callback to the
TopicTransactionBuffer.java
```java
void updateMaxReadPosition(TxnID txnID) {
PositionImpl preMaxReadPosition = this.maxReadPosition;
ongoingTxns.remove(txnID);
if (!ongoingTxns.isEmpty()) {
PositionImpl position = ongoingTxns.get(ongoingTxns.firstKey());
maxReadPosition = ((ManagedLedgerImpl)
topic.getManagedLedger()).getPreviousPosition(position);
} else {
maxReadPosition = (PositionImpl)
topic.getManagedLedger().getLastConfirmedEntry();
}
if (preMaxReadPosition.compareTo(this.maxReadPosition) != 0) {
this.changeMaxReadPositionAndAddAbortTimes.getAndIncrement();
// new added
callback.onMaxReadPostionUpdated(this.maxReadPosition);
}
}
```
Keep the code easy to understand is important, I mean if someone new to this
part to understand why we should update the `LastDataMessagePublishedTimestamp`
when adding commit and abort markers to the topic and the description of
`LastDataMessagePublishedTimestamp` said the internal marker shouldn't update
it.
@thetumbled ^^^
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
