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

Allow named tailers to be used concurrently to split work #964 #965

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from

Conversation

peter-lawrey
Copy link
Member

Previously the behaviour of concurrent named tailers with the same name was undefined and not supported.
This change adds support for splitting work by named tailer by checking whether the index has changed during the call to readingDocument
(changing the index in the table store at the end of readingDocument instead of close() )
I have added a test to show it detects and retries if the index is change while readingDocument is being performed.

@@ -195,6 +201,25 @@ public DocumentContext readingDocument(final boolean includeMetaData) {
return documentContext;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to replicate this check in the named version? or can we remove it from unnamed? it makes it more confusing if they're inconsistent

else
indexValue.setValue(index);
} else if (!indexValue.compareAndSwapValue(this.indexChecker, index)) {
this.indexChecker = Long.MIN_VALUE; // invalid.
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be better to give this a constant with a meaningful name? It's a bit hard to follow what the significance of Long.MIN_VALUE is.

}
documentContext.close();
}
throw new AssertionError();
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 possible in cases of high contention that you'd get to the end of the 100 iterations? Probably very unlikely but even if it's a remote possibility we should probably put a meaningful exception/message in here.

@nicktindall
Copy link
Contributor

nicktindall commented Dec 6, 2021

Apologies for pushing to the branch, but I just added a test to the test class that runs concurrent competing consumer threads and it doesn't seem to work. Perhaps I've missed something, alarmingly the test breaks even for a single consumer. I will note there's another test that relies on named tailers which displays similar behaviour occasionally (in QE, UngracefulShutdownTest, the same excerpt is read twice). I had always assumed the test was broken but maybe named tailers is?
I checked and this test passes on develop, so whatever the issue is, it's introduced (or made significantly more likely) by the changes on this branch

@@ -195,6 +201,25 @@ public DocumentContext readingDocument(final boolean includeMetaData) {
return documentContext;
}

DocumentContext readingDocumentNamed(final boolean includeMetaData) {
for (int i = 0; i < 100; i++) {

Choose a reason for hiding this comment

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

Under what conditions would this loop run to completion and throw the AssertionError?
Stopping after 100 iterations looks arbitrary. Is there something more robust we can do here?
It feels that the loop itself should retry indefinitely, and either succeed eventually, or internally detect any genuine error condition and throw from the body

}
Jvm.startup().on(ConcurrentNamedTailersTest.class, "Wrote " + numberOfEntries + " entries");

final int numReaders = 6;
Copy link
Contributor

Choose a reason for hiding this comment

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

this fails on my machine when numReaders = 1

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.

None yet

5 participants