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

[HUDI-8508] Fix timeline service port assignment bug #12241

Merged
merged 3 commits into from
Nov 22, 2024

Conversation

the-other-tim-brown
Copy link
Contributor

Change Logs

  • If the specified port is in use, there is no way for the server to start currently due to a bug in the logic for trying a new port. This PR updates the logic to work properly and adds a test

Impact

Fixes existing bug in timeline server code

Risk level (write none, low medium or high below)

Low

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

  • The config description must be updated if new configs are added or the default value of the configs are changed
  • Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
    ticket number here and follow the instruction to make
    changes to the website.

Contributor's checklist

  • Read through contributor's guide
  • Change Logs and Impact were stated clearly
  • Adequate tests were added if applicable
  • CI passed

@the-other-tim-brown the-other-tim-brown marked this pull request as ready for review November 14, 2024 20:39
app.start(tryPort);
return app.port();
} catch (Exception e) {
if (e.getMessage() != null && e.getMessage().contains("Failed to bind to")) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this line an error since it is introduced, is there any behavior change for Javaline itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is just a better way to do error classification. If a developer in Javalin changes the string then your handling will break so that is why you typically catch a specific exception type instead of simply Exception.

The bug is up at line 348. The underlying server object is the same and the code tries to call start on it twice and the underlying port does not change.

Copy link
Contributor

Choose a reason for hiding this comment

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

The bug is up at line 348

I didn't quite get it, the original logic invoke startService only once, where a singleton Javaline app would be created, and the startServiceOnPort would try to start a port on the app then returns, so the actual port would be updated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You can take the test case and run it against master to better see the issue. There is a server object that is passed in to Javalin that is not updated and will have the old port set.

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like the server started by Javaline is kind of sinlgeton within one JVM process, and the app can not start twice if the server already got started on a port. Do we have a scenario that multiple timeline server got triggered to start in one JVM?

Copy link
Contributor

Choose a reason for hiding this comment

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

This logic can be hit if the port is already in use on the machine

Can you supplement the test case to cover this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The test case is doing this currently, can you be more specific about what you're looking for?

Copy link
Contributor

Choose a reason for hiding this comment

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

This logic can be hit if the port is already in use on the machine

I'm not convinced by this, the used port is occupied by the Javaline app itselft, I'm wondering how it behaves if the port is assigned by stuff that is not Javaline.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, I will add another case with some lightweight server option

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a new test

@danny0405 danny0405 self-assigned this Nov 18, 2024
@hudi-bot
Copy link

CI report:

Bot commands @hudi-bot supports the following commands:
  • @hudi-bot run azure re-run the last Azure build

@github-actions github-actions bot added size:M PR with lines of changes in (100, 300] and removed size:S PR with lines of changes in (10, 100] labels Nov 22, 2024
@danny0405 danny0405 merged commit 53ef39c into apache:master Nov 22, 2024
44 of 45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:M PR with lines of changes in (100, 300]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants