A modern programming language that makes developers happier.

kotlinlang

And kudos <@UB9K6R4JH> for configuring the monitoring thanks to which we have nice insights into failures and could quantify the problem!

I think pulling the newest image and redeploying doesn't work again, see <https://hub.docker.com/layers/krzema12/github-workflows-kt-jit-binding-server/latest/images/sha256-337e459eee6fd03b91ba67e3780a0588b7f2aa5b55ba124c80a19523aa7a29d2|https://hub.docker.com/layers/krzema12/github-workflows-kt-jit-binding-server/latest[…]e459eee6fd03b91ba67e3780a0588b7f2aa5b55ba124c80a19523aa7a29d2>

metrics look much better after the latest fixes

Screenshot 2025-04-18 at 21.26.14.png

Screenshot 2025-04-18 at 21.26.29.png

cache items are kept alive until refresh (that's how I understand it)

Metrics for the metadata cache are missing :slightly_smiling_face:

<@U0152P3VB5J> is the consistency check time reasonable now?

```time .github/workflows/build.main.kts
.github/workflows/build.main.kts:9:1: warning: file 'tecolicom:actions-use-homebrew-tools___major:[v1,v2-alpha)' not found
.github/workflows/build.main.kts:9:1: warning: dependencyCollectionException: Failed to collect dependencies at tecolicom:actions-use-homebrew-tools___major:jar:[v1,v2-alpha)
.github/workflows/build.main.kts  5.43s user 0.99s system 46% cpu 13.887 total```
some binding fails to be fetched?

<https://github.com/jEdit-editor/jEdit/blob/01c732d64823f7e70e5bcc3fcb3f7ea6b7207bb8/.github/workflows/build.main.kts#L8>

Besides that it just executed successfully: <https://github.com/jEdit-editor/jEdit/actions/runs/14540692135>

First run 03:23.
Second run, so warm cache, 00:56.
Especially with the cache now staying warm also after an hour this is quite some improvement, yes, assuming it stays like that due to my ktor-client fix.

But the question is still what this "not found" is you posted

It's just a warning, but I also do not see it on the GHA execution

image.png

Ah wait, I think I still had the changed repo to the localhost (I was testing yesterday) and at that moment the server wasn't running. Sorry, false alarm

However, I don't understand the graph, why so many cache entries in the were added. Like 100?

Remember the description of the prefetch PR

That is exactly what the resolution engine for main.kts does for a version range.
It requests the POMs for all those versions in the range for whatever reason.

And because of that the prefetch would make sense to prefetch those in parallel, that they are not generated one after the other but in parallel

Oh, now I understand. Version ranges are pretty expensive then

Got it, ok... I'll think about it - the PR, just give me some more time

We could persist the current cache entries on disk and refill the cache on server startup with the persisted cache entries, that would be the next performance optimization in that regard :slightly_smiling_face: