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

[Transaction] Fix transaction timeout tracker expired problem. #10366

Conversation

congbobo184
Copy link
Contributor

Motivation

now transaction timeout tracker in expired state, it will not cancel successfully. so should add the timeout expired check

implement

add the timeout expired check

Verifying this change

Add the tests for it

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

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

Overall is good.
I left some comments about the test
PTAL

@Test
public void testTimeoutTrackerExpired() throws Exception {
pulsar.getTransactionMetadataStoreService().addTransactionMetadataStore(TransactionCoordinatorID.get(0));
Awaitility.await().atMost(2000, TimeUnit.MILLISECONDS)
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove 'atMost' as @lhotari recently suggested

txnMap.forEach((txnID, txnMetaListPair) ->
Assert.assertEquals(txnMetaListPair.getLeft().status(), TxnStatus.OPEN));
Awaitility.await().atLeast(1000, TimeUnit.MICROSECONDS).atMost(3000, TimeUnit.MILLISECONDS)
.until(() -> txnMap.size() == 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

This kind of check is probably going to become a new flaky test, because we want that something happens exactly in a given time range, but in case of long GC pause (or other unpredictable slowdown) we are going to fail the test.

Is there another way to implement this check?

Copy link
Contributor Author

@congbobo184 congbobo184 Apr 26, 2021

Choose a reason for hiding this comment

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

Regarding the timeout check, I think it can only be achieved by waiting. any good idea do you have?

field.setAccessible(true);
ConcurrentMap<TxnID, Pair<TxnMeta, List<Position>>> txnMap =
(ConcurrentMap<TxnID, Pair<TxnMeta, List<Position>>>) field.get(transactionMetadataStore);

Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we use Powermock Whitebox.getInternalState?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have not exposed the interface to call all transaction metadata information.

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant to use Whitebox.getInternalState that is a useful utility in order to not using directly reflection, that it is something that breaks from one JDK version to the next one.

not a problem for me, just a suggestion

field.setAccessible(true);
ConcurrentMap<TxnID, Pair<TxnMeta, List<Position>>> txnMap =
(ConcurrentMap<TxnID, Pair<TxnMeta, List<Position>>>) field.get(transactionMetadataStore);

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant to use Whitebox.getInternalState that is a useful utility in order to not using directly reflection, that it is something that breaks from one JDK version to the next one.

not a problem for me, just a suggestion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants