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

Oracle JDK takes significantly longer to set up #596

Closed
4 of 5 tasks
fniephaus opened this issue Feb 13, 2024 · 9 comments · May be fixed by micronaut-projects/github-actions#42
Closed
4 of 5 tasks

Oracle JDK takes significantly longer to set up #596

fniephaus opened this issue Feb 13, 2024 · 9 comments · May be fixed by micronaut-projects/github-actions#42
Assignees
Labels
bug Something isn't working

Comments

@fniephaus
Copy link
Contributor

Description:
For some reason, the time it takes to run setup-java with distribution: 'oracle' is currently significantly larger than for other distros. In this job, for example, it took 3mins, while others only need a couple of seconds (example).

Task version:
v4.0.0

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Repro steps:
Just look at the e2e tests in this repo.

Expected behavior:
Oracle JDK takes seconds to be set up.

Actual behavior:
Oracle JDK takes minutes to be setup.

Full disclosure: I work for Oracle.

@fniephaus fniephaus added bug Something isn't working needs triage labels Feb 13, 2024
@aparnajyothi-y
Copy link
Contributor

Hello @fniephaus, Thank you creating this issue and we will look into it :)

@JoseLion
Copy link

I'm having the same issue with v4. I noticed that setup-java always takes exactly 3m 0s; maybe there's a timeout or something like that? 🤔

The problem is not happening in v3, which runs setup-java in 4s even with check-latest: true.

@fniephaus
Copy link
Contributor Author

Downloading the JDK does not seem to be the problem:

2024-02-14T07:22:39.9307728Z Downloading Java 21 (Oracle) from https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.tar.gz ...
2024-02-14T07:22:39.9318293Z ##[debug]Downloading https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.tar.gz
2024-02-14T07:22:39.9321615Z ##[debug]Destination /home/runner/work/_temp/7ced4e25-0ef3-4695-9df8-6dfe1f6de8b1
2024-02-14T07:22:41.1209637Z ##[debug]download complete

To my surprise, it seems to be the creation of the settings.xml that take almost 3min:

2024-02-14T07:22:43.8694105Z Creating settings.xml with server-id: github
2024-02-14T07:22:43.8700145Z Writing to /home/runner/.m2/settings.xml
2024-02-14T07:25:40.0106698Z ##[debug]Node Action run completed with exit code 0

@fniephaus
Copy link
Contributor Author

I've tried to debug this some more and it seems that the main async function run() is just stuck when returning for some weird reason. According to why-is-node-running, there are multiple pending timeouts:

There are 1 handle(s) keeping the process running

# Timeout
node:internal/async_hooks:202                                     
node:internal/async_hooks:505                                     
node:internal/timers:160                                          
node:internal/timers:194                                          
/home/runner/work/setup-java/setup-java/dist/setup/index.js:125100 - setTimeout(function () {
/home/runner/work/setup-java/setup-java/dist/setup/index.js:125027 - function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }

setTimeout is the one I added, but the internal timers and this one look fishy:

function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }

It seems to be part of the __awaiter, which in turn wraps the run function:

var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};

At this point, I'm unable to tell whether this is a bug in the awaiter code or in Node.js.

@fniephaus
Copy link
Contributor Author

Ok, I think I got it. In my fork, setup-java takes 5s again. The problem is related to ruby/setup-ruby#543 (comment) and what I did to make it run in 5s again is to manually apply this patch to the index.js in my fork.

I'm guessing this problem is also causing other issues such as #591.

@priya-kinthali
Copy link

Hello @fniephaus 👋,
Thank you for detailed investigation on the issue and for identifying the root cause. Our investigation aligns with your findings, It seems that the problem is outside of the scope of actions/setup-java.
For now we'll proceed with closing this issue here. We appreciate your understanding and cooperation!

@fniephaus
Copy link
Contributor Author

It seems that the problem is outside of the scope of actions/setup-java.

Yes, the fix needs to be applied to @actions/http-client, but this action depends on it and the dependency needs to be updated. I'd like this ticket to be re-opened until the problem is actually resolved.

@aparnajyothi-y
Copy link
Contributor

Hello @fniephaus, The actions/toolkit#1572 released and updated actions/http-client version to 2.2.1 as part of setup-java v4.2.0 release. Tested from our end, the time difference in the post run process in v4. Please check and confirm to proceed to close this issue.

@fniephaus
Copy link
Contributor Author

I can confirm that v4.2.0 has fixed the problem. Our builds now run 3min faster again, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants