Skip to content

ConsensusQueue: acquire/release semantics, handle support#1395

Merged
vladsud merged 8 commits into
microsoft:masterfrom
vladsud:QueueAcquireRelease
Mar 5, 2020
Merged

ConsensusQueue: acquire/release semantics, handle support#1395
vladsud merged 8 commits into
microsoft:masterfrom
vladsud:QueueAcquireRelease

Conversation

@vladsud
Copy link
Copy Markdown
Contributor

@vladsud vladsud commented Mar 1, 2020

Note: I like add/acquire/release naming.
I'm not sure if "complete" is the best term to use.

* Helper method to acquire and complete an item
* Should be used in test code only
*/
export async function acquireAndComplete<T>(collection: IConsensusOrderedCollection<T>): Promise<T | undefined> {
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

Are these useful outside of test code? If so, they should be members. #Resolved

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

And if they are truly test utilities move it to a separate file and have test file import them directory.
That way they don't get exported by the package thru index.ts


In reply to: 387418180 [](ancestors = 387418180)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I moved them to separate file (testUtils), but I need to export them for end-to-end test (or make a separate package, which I do not want :))


In reply to: 387430221 [](ancestors = 387430221,387418180)


interface IConsensusOrderedCollectionAcquireOperation {
opName: "acquire";
id: string;
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

May be more explicit name? acquireId? #Resolved

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Also tsdoc for the fields.


In reply to: 387420693 [](ancestors = 387420693)

value: valueSer,
};
return this.submit(op);
await this.submit(op);
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

You can just return the Promise directly, instead of having an extra await? #WontFix

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Can't due to differences in types (void vs. IConsensusOrderedCollectionValue | undefined)


In reply to: 387424473 [](ancestors = 387424473)

while (true) {
if (this.data.size() === 0) {
// Wait for new entry before trying to remove again
await new Promise((resolve, reject) => {
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

I am wondering whether we might want to reject when the container is closing.

(Side note: we should review what each DDS behavior is like when the container is closing or closed) #Resolved

Copy link
Copy Markdown
Contributor Author

@vladsud vladsud Mar 4, 2020

Choose a reason for hiding this comment

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

Yes, we should - good catch.
I do not think we propagate close event down, so I'll open an issue to follow up.


In reply to: 387425273 [](ancestors = 387425273)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

#1420


In reply to: 387862465 [](ancestors = 387862465,387425273)

opName: "complete",
id,
};
await this.submit(work);
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

If we disconnected and then reconnected again, we will still send out an op for complete.
Should we return an error to indicate that "complete" isn't successful? #Resolved

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I've added proper events here, but I'm adding one more to make it easier to track transitions - localRelease.
There is nowhere to return an error, as completion is requested through returning ConsensusResult.Complete from callback.
I want to take an approach of seeing an actual case where eventing is not enough / not convenient before changing (or adding) API here


In reply to: 387426675 [](ancestors = 387426675)

assert(message.contents.opName === pending.message.opName);
assert(message.clientSequenceNumber === -1
|| message.clientSequenceNumber === pending.clientSequenceNumber);
assert(message.clientSequenceNumber === pending.clientSequenceNumber);
Copy link
Copy Markdown
Member

@curtisman curtisman Mar 4, 2020

Choose a reason for hiding this comment

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

I believe the -1 check might necessary for messages that are resent during disconnect? #ByDesign

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

clientSequenceNumber should never be -1.
Resend is done after catching up (with new clientID) and it just starts counting over.

init / reconnect:
this.clientSequenceNumber = 0;

Sending ops:
const message: IDocumentMessage = {
clientSequenceNumber: ++this.clientSequenceNumber,


In reply to: 387427831 [](ancestors = 387427831)

@curtisman
Copy link
Copy Markdown
Member

curtisman commented Mar 4, 2020

});

acquire and release end to end tests? #Resolved


Refers to: packages/test/end-to-end/src/test/consensusOrderedCollectionEndToEndTests.spec.ts:296 in 1f88d7b. [](commit_id = 1f88d7b, deletion_comment = False)

vladsud added 2 commits March 4, 2020 09:26
…into QueueAcquireRelease

# Conflicts:
#	packages/runtime/consensus-ordered-collection/package.json
@vladsud
Copy link
Copy Markdown
Contributor Author

vladsud commented Mar 4, 2020

});

Do you mean name of file / name of tests, or there are some cases missing in terms of coverage?


In reply to: 594304592 [](ancestors = 594304592)


Refers to: packages/test/end-to-end/src/test/consensusOrderedCollectionEndToEndTests.spec.ts:296 in 1f88d7b. [](commit_id = 1f88d7b, deletion_comment = False)

@vladsud
Copy link
Copy Markdown
Contributor Author

vladsud commented Mar 4, 2020

});

"Can add and release data" test covers it in package itself.
Adding equivalent case here as well.


In reply to: 594747266 [](ancestors = 594747266,594304592)


Refers to: packages/test/end-to-end/src/test/consensusOrderedCollectionEndToEndTests.spec.ts:296 in 1f88d7b. [](commit_id = 1f88d7b, deletion_comment = False)

Copy link
Copy Markdown
Member

@curtisman curtisman left a comment

Choose a reason for hiding this comment

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

:shipit:

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.

2 participants