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

IGNITE-24242 Add RO/RW Transaction Timeout configuration schema #5093

Merged
merged 21 commits into from
Jan 30, 2025

Conversation

PakhomovAlexander
Copy link
Contributor

Comment on lines 62 to 66
public final long roTimeout = 10_000;

@Range(min = 1)
@Value(hasDefault = true)
public final long rwTimeout = 3_000;
Copy link
Contributor

Choose a reason for hiding this comment

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

There is already timeout which defines default timeouts. Now, rwTimeout and roTimeout are added. Do they serve the same purpose? If yes, timeout should probably be removed.

But if it's removed, it's a breaking change (as 3.0 code freeze has already happened) and it should be handled in a different way, probably by declaring it as deprecated and, maybe, using the existing value for some time?

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we still can do breaking changes in configuration APIs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

timeout removed

@@ -418,7 +418,9 @@ public class TableManager implements IgniteTablesInternal, IgniteComponent {

private final PartitionReplicaLifecycleManager partitionReplicaLifecycleManager;

private long implicitTransactionTimeout;
private long roTransactionTimeout;
Copy link
Contributor

Choose a reason for hiding this comment

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

Tx timeout is tx specific attribute, meaning that tx1 will have 100ms as timeout and tx2 that is running at the same time 2000ms. In that case why roTransactionTimeout and rwTransactionTimeout are here?
Besides that, it's just an encapsulation leak - simply TableManager should not know about such things.
I'd rather say that on tx creation we should populate TransacionOptions with default timeout from cfg if it's not specified by the user and within tx flow use timeout from the tx context - no need to propagate txTimeout to InternalTableImpl etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you agree that implicitTransactionTimeout should be removed with this PR? If yes, then it is clear why these options are there. If we should keep implicitTransactionTimeout then, probably, I should rollback the change.

I suppose we should remove implicitTransactionTimeout and refactor TableManager as you suggested. Am I right?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to remove implicitTransactionTimeout

Copy link
Contributor

@rpuch rpuch Jan 27, 2025

Choose a reason for hiding this comment

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

In that case why roTransactionTimeout and rwTransactionTimeout are here?

I thought these properties define default TX timeouts. A default is global and not specific to a transaction.

Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose we should remove implicitTransactionTimeout and refactor TableManager as you suggested. Am I right?

Yes.


@Range(min = 1)
@Value(hasDefault = true)
public final long maxRoTimeout = Long.MAX_VALUE;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why it's not equal to dataAvailabilityTime?

Copy link
Contributor

@rpuch rpuch Jan 23, 2025

Choose a reason for hiding this comment

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

(deleted as irrelevant)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

property deleted


@Range(min = 1)
@Value(hasDefault = true)
public final long maxRwTimeout = Long.MAX_VALUE;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it too much for default max value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

property deleted


@Range(min = 1)
@Value(hasDefault = true)
public final long maxRoTimeout = Long.MAX_VALUE;
Copy link
Contributor

Choose a reason for hiding this comment

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

Here and there: for such properties it's reasonable to have milis(or any other) suffix.

Copy link
Contributor

Choose a reason for hiding this comment

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

There was a proposal to switch duration-related properties type to Duration and allow the user specify units in the config. Having this in mind, it seems that we should not include units in property names.

My comment only makes sense if we still want to have that feature in the configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

property deleted


@Range(min = 1)
@Value(hasDefault = true)
public final long maxRoTimeout = Long.MAX_VALUE;
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the purpose of
minRoTimeout maxRoTimeout minRwTimeout maxRwTimeout ?
It doesn't make sense to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree. Will drop these properties.

Comment on lines 62 to 66
public final long roTimeout = 10_000;

@Range(min = 1)
@Value(hasDefault = true)
public final long rwTimeout = 3_000;
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we still can do breaking changes in configuration APIs.


@Range(min = 1)
@Value(hasDefault = true)
public final long roTimeout = 10_000;
Copy link
Contributor

Choose a reason for hiding this comment

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

How these defaults are calculated?
They seem too low.
I suggest 10 minutes for RO txns, and 30 seconds for RW txns

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good suggestion.

long ts = (txStartTs == null) ? actualTx.startTimestamp().getPhysical() : txStartTs;

if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < implicitTransactionTimeout) {
if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < timeout) {
Copy link
Contributor

Choose a reason for hiding this comment

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

How about extracting the if condition to a method? It's used a few times in this same form

@Range(min = 1)
@Value(hasDefault = true)
public final long timeout = 10_000;
Copy link
Contributor

Choose a reason for hiding this comment

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

This still looks like a breaking change. Let's consult @ptupitsyn whether we are allowed to directly remove a configuration property

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch. But why should we consult Pavel about changing the property we've added a couple of weeks ago?

Copy link
Contributor

Choose a reason for hiding this comment

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

Because 3.0.0 already contains transaction.timeout config property. If we just remove it, then our next release will potentially break them.

@@ -475,7 +483,7 @@ private ReadOnlyTransactionImpl beginReadOnlyTransaction(
}

private long roExpirationPhysicalTimeFor(HybridTimestamp beginTimestamp, InternalTxOptions options) {
long effectiveTimeoutMillis = options.timeoutMillis() == 0 ? defaultTransactionTimeoutMillis() : options.timeoutMillis();
long effectiveTimeoutMillis = options.timeoutMillis() == 0 ? defaultReadOnlyTransactionTimeoutMillis() : options.timeoutMillis();
Copy link
Contributor

Choose a reason for hiding this comment

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

This calculation is repeated at least twice. Let's extract it to a method

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The next ticket will change this, don't you mind to leave this as is?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm ok with this if this will not be forgotten :)


@Override
public long timeout() {
return 10_000;
Copy link
Contributor

Choose a reason for hiding this comment

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

10_000 is used for the same purpose in multiple places. Should we extract it somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The next ticket will change this, don't you mind to leave this as is?

Copy link
Contributor

@rpuch rpuch left a comment

Choose a reason for hiding this comment

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

The only concern that still remains from my side is the compatibility issue, let's sort it out

@PakhomovAlexander PakhomovAlexander merged commit 25f5e78 into apache:main Jan 30, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants