[fix][txn] fix concurrent error cause txn stuck in TransactionBufferHandlerImpl#endTxn

[TakaHiR07]

Fixes #23550

Motivation

After diving into the code, finding that there is a concurrent error in TransactionBufferHandlerImpl#checkRequestCredits(), checkPendingRequests(), which would cause the above issue.

Currently, we have config TransactionBufferClientMaxConcurrentRequests to control the concurrent request number. However, if the request and response is executed as follow, the request would permanently stuck in queue.
(to simplify the case, let's set permit is 1)

step	request-1	request-2	response-1	request-3
1	start do checkRequestCredits()
2	compareAndSet requestCredits to 0
3	execute endTxn
4		start do checkRequestCredits()
5		get currentPermit = 0
6			trigger onResponse(), set requestCredits to 1
7			trigger checkPendingRequests(), permit == 1 && pendingRequests is null, so break the while process
8		currentPermits == 0 && pendingRequest is null, then add op to pendingRequest
9				start do checkRequestCredits()
10				currentPermit == 1 && pendingRequests is not null , also add op to pendingRequest

Now we can find there is no response can trigger pendingRequest.remove, and then all the new requests just add to pendingRequest but permanently not execute.

Modifications

The root reason is currently only onResponse() can trigger pendingRequest.remove. But when we execute onResponse(), the requestOp may not have been added to pendingRequest.

• So one modification is to let it can check the pendingRequest queue in checkRequestCredits()
• And the while(true) in checkPendingRequests() is not necessary, 1 response come back, take 1 requestOp from pendingRequest is OK.

It is hard to add test for this concurrent case.

Verifying this change

• Make sure that the change passes the CI checks.

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:

[TakaHiR07]

@codelipenghui @congbobo184 Can you help review this pr?

[lhotari]

just wondering if deeply nested recursive calls could become a problem. is there a specific reason to replace the while loop with recursion?

[TakaHiR07]

Because the while loop looks somewhat confusing, it look like 1 response can trigger taking multiple requests from pendingRequest. But actually it is executed when its permit > 0 . And permit would +1 when 1 response return.

And let's assume a scene, 100 responses come back at the same time, both of them would go into while loop and compete for acquire the permits. Now the permits is 100 and pendingRequestQueue is also 100, then all of the responses would compete for taking all requests from queue. That is not neccessary.

So I replace to 1 response trigger take 1 request from pendingRequestQueue. And only two case we should do recursion to retry:

• If the request taking is null, we should retry checkPendingRequest() to take the next one.
• If permit.compareAndSet is not successful, it means there is concurrent checkRequestCredits() or checkPendingRequest(), we should retry checkPendingRequest() again to make sure response can trigger taking 1 request from pendingRequestQueue

[TakaHiR07]

The recursive calls actually may be problem. I have updated the code, the new one is better.

[lhotari]

LGTM

[congbobo184]

LGTM