-
Notifications
You must be signed in to change notification settings - Fork 104
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
Conversation
2b826b9
to
68f1fa8
Compare
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
public final long roTimeout = 10_000; | ||
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long rwTimeout = 3_000; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to remove implicitTransactionTimeout
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRoTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(deleted as irrelevant)
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
property deleted
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long maxRoTimeout = Long.MAX_VALUE; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
public final long roTimeout = 10_000; | ||
|
||
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long rwTimeout = 3_000; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion.
…e updated, we will use up-to-dated values.
...rc/main/java/org/apache/ignite/internal/tx/configuration/TransactionConfigurationSchema.java
Outdated
Show resolved
Hide resolved
…tx/configuration/TransactionConfigurationSchema.java Co-authored-by: Roman Puchkovskiy <[email protected]>
(will be changed in the next ticket)
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Outdated
Show resolved
Hide resolved
long ts = (txStartTs == null) ? actualTx.startTimestamp().getPhysical() : txStartTs; | ||
|
||
if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < implicitTransactionTimeout) { | ||
if (exceptionAllowsImplicitTxRetry(e) && coarseCurrentTimeMillis() - ts < timeout) { |
There was a problem hiding this comment.
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
...le/src/main/java/org/apache/ignite/internal/table/distributed/storage/InternalTableImpl.java
Show resolved
Hide resolved
@Range(min = 1) | ||
@Value(hasDefault = true) | ||
public final long timeout = 10_000; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
...sactions/src/main/java/org/apache/ignite/internal/tx/impl/IgniteAbstractTransactionImpl.java
Outdated
Show resolved
Hide resolved
...sactions/src/main/java/org/apache/ignite/internal/tx/impl/IgniteAbstractTransactionImpl.java
Outdated
Show resolved
Hide resolved
@@ -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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
…tx/impl/IgniteAbstractTransactionImpl.java Co-authored-by: Roman Puchkovskiy <[email protected]>
There was a problem hiding this 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
https://issues.apache.org/jira/browse/IGNITE-24242