[
https://issues.apache.org/jira/browse/CAMEL-26443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26443.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/28778 (merged as 0c2d47782501).
The update check writes last_checked before the fetch, and the CLI waits up to
2 seconds for the refresh at the end of a command, so a quick command refreshes
the cache too. The fetcher closes its HttpClient so the JVM exits without the
delay of the selector thread.
_Claude Code on behalf of davsclaus (Claus Ibsen)_
> camel-launcher - The update check of the web installer never refreshes its
> cache from a quick command
> -----------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26443
> URL: https://issues.apache.org/jira/browse/CAMEL-26443
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.24.0
>
>
> The launcher of the web installer checks once a day for a newer release
> ({{UpdateChecker}}): when its cache ({{update-check.properties}}) is older
> than 24 hours, a daemon thread fetches {{latest.properties}} from
> camel.apache.org and then writes the cache. Since the startup work of
> CAMEL-23810 a quick command such as {{camel version}} or {{camel ps}} ends
> (about 170 ms) before that thread has even sent its request, so the JVM stops
> it, and nothing is written: a user who runs only quick commands never sees
> the notice of a new release, and every quick command starts the fetch again.
> Only a long command ({{camel run}}, {{camel tui}}) refreshed the cache.
> Measured with a manifest server that answers in 50 ms: 8 runs of {{camel
> version}} with a stale cache sent no request; {{camel run --max-seconds=3}}
> did, and the next {{camel version}} printed the notice.
> The fix:
> * the check is marked ({{last_checked}}) before the fetch, so a failed or
> slow fetch is not tried again by the next commands, but the next day;
> * the launcher waits after the command for the fetch that it started, at most
> 2 seconds (so once a day);
> * the HTTP client of the fetch is closed, as its selector thread delays the
> exit of the JVM by about 300 ms.
> The run of the day then takes about 120 ms more than another run with a fast
> server (302 ms instead of 180 ms, and 615 ms without closing the client).
> _Claude Code on behalf of davsclaus (Claus Ibsen)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
