Skip to content

Conversation

@ajbeamon
Copy link
Contributor

Fix some issues with persisting these options in the multi-version client. Make size limit option not persistent.

@ajbeamon
Copy link
Contributor Author

Fixes #1435

@ajbeamon
Copy link
Contributor Author

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.

Copy link
Contributor

@alecgrieser alecgrieser left a 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);
Copy link
Contributor

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?

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 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.

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 can add a comment to this effect.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

ajbeamon added 2 commits June 28, 2019 13:24
…b.options. Fix some issues with persisting these options in the multi-version client. Make size limit option not persistent.
@ajbeamon ajbeamon force-pushed the fix-mvc-default-options branch from be19eeb to c6df30d Compare June 28, 2019 20:25
@AlvinMooreSr
Copy link
Contributor

@fdb-build test this please

}
catch (Error& e) {
retryCount++;
if (retryCount == 10)
Copy link
Contributor

@jzhou77 jzhou77 Jul 2, 2019

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?

Copy link
Contributor Author

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.

private string _comment;
public bool persistent { get; set; }
public int defaultFor { get; set; }
private string _comment;
Copy link
Contributor

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");
Copy link
Contributor

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.

Copy link
Contributor

@jzhou77 jzhou77 left a 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.

@alecgrieser
Copy link
Contributor

Looks like the macOS build is complaining about missing options in a switch statement:

fdbclient/NativeAPI.actor.cpp:753:10: error: 4 enumeration values not handled in switch: 'TRANSACTION_TIMEOUT', 'TRANSACTION_RETRY_LIMIT', 'TRANSACTION_MAX_RETRY_DELAY'... [-Werror,-Wswitch]
                switch(option) {

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).
@ajbeamon
Copy link
Contributor Author

ajbeamon commented Jul 3, 2019

Ok, I've run the binding tester on this against a 6.1 cluster using libfdb_c.so from this branch as the primary library, and it worked as expected.

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.
@ajbeamon
Copy link
Contributor Author

ajbeamon commented Jul 9, 2019

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?

@ajbeamon
Copy link
Contributor Author

ajbeamon commented Jul 9, 2019

Well, I guess I need to merge master first and resolve some conflicts.

# Conflicts:
#	documentation/sphinx/source/release-notes.rst
@alecgrieser
Copy link
Contributor

Well, looks good modulo the failing build.

@ajbeamon
Copy link
Contributor Author

Looking at one of the checks, it looks like there are disk space issues.

@alecgrieser
Copy link
Contributor

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 NativeAPI.actor.cpp.

# Conflicts:
#	fdbclient/NativeAPI.actor.cpp
@ajbeamon
Copy link
Contributor Author

Checks have all passed now

@alecgrieser alecgrieser merged commit a72d5b5 into apple:master Jul 10, 2019
@ajbeamon ajbeamon deleted the fix-mvc-default-options branch July 10, 2019 21:45
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