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

chore: strange case not closing stream #50

Merged
merged 4 commits into from
Jun 3, 2022
Merged

Conversation

menduz
Copy link
Member

@menduz menduz commented May 25, 2022

No description provided.

Comment on lines +96 to +114
/**
* If a StreamMessage is received, then it means we have the POSSIBILITY to
* consume a remote generator. The client must answer every ACK with the next
* inteded action, could be: next(), close(). Both actions are serialized in the
* StreamMessage. The server MUST NOT generate any new element of the generator
* if the client doesn't ask for it.
*
* The whole protocol is designed to be SLOW AND SECURE, that means, ACKs (slow)
* will block the generation and consumption of iterators (secure).
*
* That exist to save the memory of the servers and to generate the much needed
* backpressure.
*
* If throughput is what you are looking for, you may better use bigger messages
* containing serialized lists. Effectively reducing the number of messages
* and increasing their size.
*
* @internal
*/
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link

@hugoArregui hugoArregui left a comment

Choose a reason for hiding this comment

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

Awesome work!

S-->C: StreamMessage {message_id,payload,seqId=2}
C->S: StreamMessage {ack=true,message_id,seqId=2,closed=true}
S->S: Close async Generator
C->C: Close async Iterator
Copy link
Contributor

Choose a reason for hiding this comment

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

should this close async iterator be here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean the C->C: Close async Iterator is duplicated and I think the last one is the right.

Copy link
Member Author

Choose a reason for hiding this comment

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

the server has a generator, the client has an iterator. I think it is sound

@menduz menduz merged commit 20bf1db into main Jun 3, 2022
@menduz menduz deleted the chore/failing-close-test branch June 3, 2022 14:48
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.

3 participants