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

Fix issues in URI parser from folly #156

Open
raakella1 opened this issue Mar 15, 2024 · 3 comments
Open

Fix issues in URI parser from folly #156

raakella1 opened this issue Mar 15, 2024 · 3 comments
Assignees
Milestone

Comments

@raakella1
Copy link
Contributor

We use folly::Uri to parse the string we get from lookup call in repl service. There are several issues here

  • It throws exceptions other than runtime error (invalid arg etc). We should handle them properly
  • folly Uri expects the port to be uint16_t and storage mgr expects it to be uint32_t. Folly will throw if we set port greater that uint_16 max (65535)
@raakella1 raakella1 added this to the MileStone4.2 milestone Mar 15, 2024
@xiaoxichen
Copy link
Collaborator

I get the first one (exception handling) however do not understand second one.... how can a port greater than uint16 which is defined in TCP/UDP protocol??

@raakella1
Copy link
Contributor Author

I get the first one (exception handling) however do not understand second one.... how can a port greater than uint16 which is defined in TCP/UDP protocol??

In my SM testing scripts, I am randomizing ports so that developers using the same build machine can parallelly use my scripts. Initially I used a random number between 5000, 99999 as a port. When ever the port value for home repl is greated than uint16::max, uri parser throws. All the other services (grpc, http etc) did not complain. Even in the SM config, we define hr_port as a uint32 variable which does not aligh with uri parser limits

@xiaoxichen
Copy link
Collaborator

xiaoxichen commented Mar 18, 2024

that is something we need to handle in the command line check right? there is no possibility for you to open a port larger than 65535.

All the other services (grpc, http etc) did not complain.

As the max port number in TCP is 65535. I believe the listen call should error out if 99999 specified, is that indicating we have a bug in error handling there?

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

No branches or pull requests

2 participants