You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
setup-java post action caching for v4 is slower than v3 #601
Expected behavior:
v4 should have the same speed as v3.
Both executions had no cache hits and the amount of data was approx 30MB.
Actual behavior:
v4 is in this case orders of magnitude slower than v3.
Additional information:
I have seen that actions setup-node actions/setup-node#878
and setup-ruby ruby/setup-ruby#543 have had the same problem.
It seems that it had to do with the upgrade of the actions/cache version.
I think their solution was to exit the process manually after caching is complete as otherwise the job simply hangs until some timeout.
After looking at this repo for a very short time my guess is that perhaps somewhere
here ->
Hello @htpaf, Thank you once again for creating this issue.
We have investigated about the issue and able to reproduce the issue but there is no major changes in setup-java that affect the performance time from v3 to v4 other than node 20 upgrade. We tried multiple scenarios and found that the this long time duration is due to the dependencies installation time for node20. As per the node.js official documentation for node 20, we found that from node v19, Global instance of Agent uses keep-alive by default for all HTTP client requests .And the current usage is - HttpClient implementation uses globalAgent when RequestOptions.keepAlive is set to false.
There is a PR is the fix for the same is merged to actions/toolkit repository. The issue resolves after RequestOptions.keepAlive is applied properly on node20 runtime. Please find the screenshot for reference.
We will update you once the changes released. Thank you.
Thank you for the update and work on this issue @aparnajyothi-y .
This issue is related to if not a duplicate of #591.
I read the comments over there and @fniephaus mentions the toolkit problem.
I am thinking that keepAlive setting might solve the problem but the fix done for other actions such as this setup-ruby fix seems relevant. It would seem better to explicitly complete/end the request not wait for a timeout, whose actual value could be changed upstream at any time, and then have better guarantees and not get regressions.
Hello everyone, 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.
Activity
v-HarithaVattikuti commentedon Feb 29, 2024
Hello @htpaf
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.
v-aparnajyothi-y commentedon Mar 4, 2024
Hello @htpaf, Thank you once again for creating this issue.
We have investigated about the issue and able to reproduce the issue but there is no major changes in setup-java that affect the performance time from v3 to v4 other than node 20 upgrade. We tried multiple scenarios and found that the this long time duration is due to the dependencies installation time for node20. As per the node.js official documentation for node 20, we found that from node v19, Global instance of Agent uses keep-alive by default for all HTTP client requests .And the current usage is - HttpClient implementation uses globalAgent when RequestOptions.keepAlive is set to false.
There is a PR is the fix for the same is merged to actions/toolkit repository. The issue resolves after RequestOptions.keepAlive is applied properly on node20 runtime. Please find the screenshot for reference.
We will update you once the changes released. Thank you.
htpaf commentedon Mar 7, 2024
Thank you for the update and work on this issue @aparnajyothi-y .
This issue is related to if not a duplicate of #591.
I read the comments over there and @fniephaus mentions the toolkit problem.
I am thinking that keepAlive setting might solve the problem but the fix done for other actions such as this setup-ruby fix seems relevant. It would seem better to explicitly complete/end the request not wait for a timeout, whose actual value could be changed upstream at any time, and then have better guarantees and not get regressions.
Does that make sense @aparnajyothi-y ?
htpaf commentedon Mar 8, 2024
The toolkit PR is released in
this PR and
setup-java uses the 2.2.1 version in this PR.
A release PR for setup-java from
action:maintomainbranch is probably what makes it generally available inv4.It should be possible to use the setup-java PR branch to test already... but it is a fork so probably not until it is in this repository.
v-aparnajyothi-y commentedon Mar 8, 2024
Hello @htpaf, Thank you for the information, We will get back you soon on this.
htpaf commentedon Mar 11, 2024
I tried with setup-java@main (given this merged PR) and got:
This looks much better! Great work!
So yes @aparnajyothi-y looking forward to when the v4 tag will contain this update.
v-aparnajyothi-y commentedon Mar 15, 2024
Hello everyone, 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.
htpaf commentedon Mar 18, 2024
Verified with 99b8673 corresponding to https://github.com/actions/setup-java/releases/tag/v4.2.1
So all good.