-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Make default and persistent options specifyable via annotations to fdb.options... #1767
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
Conversation
|
Fixes #1435 |
|
I have two tests to try which I haven't yet -- that this works as expected when connecting to a 6.1 cluster through the multi-version client and that the behavior works correctly during version switches. |
alecgrieser
left a comment
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 think this mostly looks good. It might also require a release note (or something) that one should use the 6.2 client as the primary client in multi-version configurations in order to properly handle these things unless the 6.1 client works (but I think it would have problems).
| } | ||
|
|
||
| if(timeout.present()) { | ||
| newTr.transaction->setOption(FDBTransactionOptions::TIMEOUT, 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.
Why is timeout handled separately like this?
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 think it's the case that setting the timeout can immediately end a transaction if the timeout has elapsed. This can cause a problem if, for example, you set a database default at 1 second and then override it to 5 seconds on the transaction. If the transaction has run for 2 seconds and you apply both timeouts, the database default will then cause you to fail.
The special logic here is to make sure we only set the most recent value of the 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.
I can add a comment to this effect.
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.
Hm, wait, if persistentOptions were a UniqueOrderedOptionList, would that solve this? Or is there some reason it can't be one of those?
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.
That would do it, and I could be convinced to go that route for persistent options. The reason I didn't was because it also imposes the constraint that persistent options cannot have cumulative effects (like database defaults), and I made the choice to not do that since this workaround was easy enough.
It's not a position I hold strongly, though, so feel free to change my mind.
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.
None of the current persistent options have cumulative effects, right? So, if this went in as is, we could change it to use the UniqueOrderedOptionList later? Maybe we should keep it, then, as it doesn't restrict our options.
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.
Yes, I believe that to be the case.
…b.options. Fix some issues with persisting these options in the multi-version client. Make size limit option not persistent.
be19eeb to
c6df30d
Compare
|
@fdb-build test this please |
| } | ||
| catch (Error& e) { | ||
| retryCount++; | ||
| if (retryCount == 10) |
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.
Where do we handle the retry logic now? At some transaction class now?
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.
Oh good catch, this was from me trying to delete something else. I'll add this logic back.
Use emplace_back instead of push_back Co-Authored-By: Jingyu Zhou <[email protected]>
| private string _comment; | ||
| public bool persistent { get; set; } | ||
| public int defaultFor { get; set; } | ||
| private string _comment; |
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.
Use space to be consistent.
| bool persistent = oDoc.AttributeOrNull("persistent") == "true"; | ||
| String defaultForString = oDoc.AttributeOrNull("defaultFor"); | ||
| int defaultFor = defaultForString == null ? -1 : int.Parse(defaultForString); | ||
| string disableOn = oDoc.AttributeOrNull("disableOn"); |
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.
For these two lines, use space to be consistent.
jzhou77
left a comment
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.
LGTM. There are a couple of space formatting comments inlined.
|
Looks like the macOS build is complaining about missing options in a switch statement: Those are the database-wide options, so they are being handled, just not the way it thinks. I'm not sure if a default statement just to put a comment is the right thing or not. |
…ing options (and logging for present options).
|
Ok, I've run the binding tester on this against a 6.1 cluster using I've also run a few tests of timeouts during upgrades, and they all worked as expected. I tested a timeout set as a database default, as a transaction option (set once at the beginning), and setting both, with the default short and the transaction timeout long. In all cases, the timeouts fired the expected amount of time after the upgrade. It is the case that any state about the current elapsed time or retry count is lost, but I'm not sure whether we want to go the route of trying to address that. I don't think it's within scope of this PR, at any rate. |
…ient must be used as the primary for the behavior to work correctly.
|
I've updated the release notes, as suggested. I don't think there are any other requested changes, can you confirm and merge if it looks good? |
|
Well, I guess I need to merge master first and resolve some conflicts. |
# Conflicts: # documentation/sphinx/source/release-notes.rst
|
Well, looks good modulo the failing build. |
|
Looking at one of the checks, it looks like there are disk space issues. |
|
Yeah, I think these are the things Alex said he resolved by freeing up some space. I'd say we just run t*st this please except for the new conflict in |
# Conflicts: # fdbclient/NativeAPI.actor.cpp
|
Checks have all passed now |
Fix some issues with persisting these options in the multi-version client. Make size limit option not persistent.