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

feat: introduce handshake to client and gRPC server #36

Merged
merged 5 commits into from
Apr 14, 2023

Conversation

KeranYang
Copy link
Member

@KeranYang KeranYang commented Apr 13, 2023

Java implementation of numaproj/numaflow-go#42

Testing

  • Unit Test
  • Manually built a new image and ran the corresponding e2e test.

@KeranYang KeranYang requested review from yhl25 and whynowy April 13, 2023 13:49
@KeranYang KeranYang marked this pull request as ready for review April 13, 2023 14:50
FileWriter fileWriter = new FileWriter(filePath, false);
objectMapper.writeValue(fileWriter, serverInfo);
FileWriter eofWriter = new FileWriter(filePath, true);
eofWriter.append("\n").append(ServerInfoConstants.EOF);
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to add \n?

StringBuilder stringBuilder = new StringBuilder();
String line;
while ((line = bufferedReader.readLine()) != null
&& !line.equals(ServerInfoConstants.EOF)) {
Copy link
Member

Choose a reason for hiding this comment

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

I guess \n is for this.

I think it's better to use endWith() to check and trim.

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't have to add \n, I just feel it looks prettier when EOF is at a newline :). I also made corresponding changes in numaproj/numaflow-go#48 to make sure the parsing is consistent.

Signed-off-by: Keran Yang <[email protected]>
Signed-off-by: Keran Yang <[email protected]>
.
Signed-off-by: Keran Yang <[email protected]>
@KeranYang KeranYang merged commit 33b9bc9 into numaproj:main Apr 14, 2023
* Please exercise cautions when updating the values below because the exact same values are defined in other Numaflow SDKs
* to form a contract between server and clients.
*/
public enum Language {
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason why we didn't go with proto? Since it's common among all the sdks we could have kept a common proto file

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point Yashash. I think we should go with proto, that way we can catch any data format issue during development instead of runtime. @whynowy @vigith thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

+1, we need to standardize our proto location before we do that. today we manually sink it between the repos.

Copy link
Member Author

Choose a reason for hiding this comment

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

To be addressed by numaproj/numaflow#693

* Please exercise cautions when updating the values below because the exact same values are defined in other Numaflow SDKs
* to form a contract between server and clients.
*/
public enum Protocol {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment

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.

4 participants