[ 
https://issues.apache.org/jira/browse/CAMEL-26443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on CAMEL-26443 started by 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)

Reply via email to