Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
kotlin: grpc codec #472
kotlin: grpc codec #472
Changes from all commits
dd792ce
3285b8a
4a52d9f
4b4fe3e
b3efc58
40fa71c
ed5303a
0ea81a1
2aec367
18fbaba
5c58e19
c51ac3b
b1c6434
504086d
c492720
852de8b
6d73e7b
a14ebb7
9ac52b4
ba42039
2ae952f
3a545c3
76b9839
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can update iOS with this functionality as well (bailing and calling
onError
if this happens)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The important detail here is that we still keep the stream alive 😬
If we can safely close the stream, that would be much much better.
I just left it like this for now since I do consider this a volatile feature and the behavior is a bit up in the air with respect to messages which are gRPC compressed. If we appropriately close the stream, it feels more of a intentional design to exclude compression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we just call
close()
here and call the consumer withonError
? I think that'd be a good way to shut down safelyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't
close()
only propagate downward to the user rather than upward to Envoy?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also don't have a
close()
handler in the response caseThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aha right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized why I didn't do this originally on iOS. Storing the
errorClosure
on theGRPCResponseHandler
is problematic because nothing necessarily keeps theGRPCResponseHandler
in memory since only the closures need to stick around. When I ended up using theGRPCResponseHandler
in practice, this was totally fine because the closures passed to the underlying callbacks have their own lifecycle. Maybe we should just assert here instead?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#515
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming the language does the right thing here and does the conversion to native format when you call
.int
below this should be fineThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it will write it in big endian here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this end up doing additional copying when we reset then re-
write
bytes?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it does an additional copy. If it helps any, we do use
ByteArrayOutputStream
as our unoptimizedByteArray
I/O sink. We can revisit this strategy pretty easily further down the roadThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding a todo with optimization notes 🤷♂