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

test_retry_non_txn slow with serializable&non-pushable #3

Open
tbg opened this issue Mar 25, 2015 · 5 comments
Open

test_retry_non_txn slow with serializable&non-pushable #3

tbg opened this issue Mar 25, 2015 · 5 comments

Comments

@tbg
Copy link
Member

tbg commented Mar 25, 2015

Adding to @bdarnell's comment in test_retry_non_txn:

# The write/write can't-push test cases take 15 seconds each.
# TODO: why? because the go version uses Store.SetRangeRetryOptions?
#(Methods.Put, data_pb2.SNAPSHOT, False, 1),
#(Methods.Put, data_pb2.SERIALIZABLE, False, 1),
# Read/write conflicts.

I have found that the test cases present still incur a 15sec wait for me, unless I comment the last one:

        test_cases = [
            # Write/write conflicts.
            (Methods.Put, data_pb2.SNAPSHOT, True, 2),
            (Methods.Put, data_pb2.SERIALIZABLE, True, 2),
            # The write/write can't-push test cases take 15 seconds each.
            # TODO: why? because the go version uses Store.SetRangeRetryOptions?
            #(Methods.Put, data_pb2.SNAPSHOT, False, 1),
            #(Methods.Put, data_pb2.SERIALIZABLE, False, 1),
            # Read/write conflicts.
            (Methods.Get, data_pb2.SNAPSHOT, True, 1),
            (Methods.Get, data_pb2.SERIALIZABLE, True, 2),
            (Methods.Get, data_pb2.SNAPSHOT, False, 1),
            #(Methods.Get, data_pb2.SERIALIZABLE, False, 1),
        ]

This test appears to be reliably slow (~19sec for all tests) with the last case, and fast (~4sec for all tests) without it.

@bdarnell
Copy link
Contributor

Yeah, I saw this too. Not sure why I commented out two of the slow cases and left the third. I apparently have about 20 seconds worth of patience for a test run.

@spencerkimball
Copy link
Member

Perhaps we can add something to the RequestHeader for retries...?

@bdarnell
Copy link
Contributor

But that's not generally something we want to let the clients control, is it? I was thinking the answer would be to pass in extra flags when starting the docker container.

@spencerkimball
Copy link
Member

Yeah, probably not. Having these settable via flags from container sounds OK.

@tbg
Copy link
Member Author

tbg commented May 11, 2015

probable root cause: cockroachdb/cockroach#877

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

No branches or pull requests

3 participants