Maven Central search results should be cached

[fbricon]

In order to avoid unnecessary HTTP requests, responses for Maven Central search queries should be cached in memory, for several minutes (period could be made configurable). See fbricon/m2e-core@f46db07#diff-15b5813d8fe377232c05123e45e1b1dda3d2ae85211fc3102c8f1e49e7cb2b36R55-R56 as an example.

Limiting http requests will help both users, by providing fast results, and not pound Sonatype's infra with a shitton of queries from all over the place.

[vrubezhny]

@fbricon Do you think having such a cache to be stored only "in memory" and maintained without any persistence would be enough?

What is expected to be cached: Collections of Strings for GroupIDs,, Artifact objects and ArtifactVersion objects provided by https://github.com/eclipse/lemminx-maven/blob/master/lemminx-maven/src/main/java/org/eclipse/lemminx/extensions/maven/searcher/RemoteCentralRepositorySearcher.java#L39.

[angelozerr]

I think if we have an embed database like H2 or other, should b ereally nice, it will avoid have the same problem when Eclipse IDE will restart.

[mickaelistria]

I'm not sure a cache would help much in general. Is there a particular request you see being repeated very often in practice?

[vrubezhny]

@angelozerr IMHO, I don't see any persistence to be required here and personally I plan to drop the cached values after 30 minutes to 1 hour timeout. Not sure about the timeout value, but when we're about to edit a POM adding some new dependency - this is the only when RemoteCentralRepositorySearcher is to be used.
How many times during he session you would search for an artifacts/groups and versions for the dependency artifact? In next 15 minutes you'll probably will be editing a completely different files and probably will never return to the same POM and dependency.

@mickaelistria IMHO the cache will be really helpful "right here and right now" while you may repeatedly invoke Completions during adding/editing exactly this current dependency - it takes like 10-15 minutes as maximum, no? I don't expect anything other than adding a few in-memory HashMaps here and purging them out after 30-minutes - 1 hour of inactivity. And especially it will be useful in slow internet or interruptions that often occur with Maven Search API server(-s).
IMHO.

[mickaelistria]

IMHO the cache will be really helpful "right here and right now" while you may repeatedly invoke

I don't fully get what would be cached and when it is cached, when the cache is used... Can you please give more concrete example?

[vrubezhny]

@mickaelistria RemoteCentralRepositorySearcher is used to provide GroupIDs, Artifacts for a groupID and Versions of an artifactID on Content Assist requests - i.e. while you editing a POM.

So, when you are adding a dependency/plugin - completions are searched by Maven Search API - for some requests it usually it takes 0.5 - 2 seconds to get the results from Maven Search API or even longer, including the requests might "hang" and never complete despite a timeout set for these operations.

Having the successfully received values cached will help to speed-up on repeated content assist invocations while continue editing the same dependency/plugin (changing groupsID/artifactID/Version of the same dependency/plugin) and may be while adding another dependency of the cached groupID.

Not used in diagnostics/definitions/code actions/hovers/etc.

[fbricon]

15 min cache should be enough.

[mickaelistria]

Are repeated content assist executions a real thing? Do the Maven Central search API return all results (so we know cache will contain the necessary result as user continues typing? What would be the key in such a cache?

[vrubezhny]

@mickaelistria When "user continue typing" -is probably a different case... Completion is not repeatedly invoked in most of such cases - the filtering the existing results happens.
When user changes to another position/starts adding another element (like artifact Id after , group id, or version after the first two ones) or another plugin/dependency - completion is most likely invoked. Here the cached groupIDs most likely are to be used, or a cached set of artifacts.
After that if user returns to editing of first plugin/dependency elements - completion will be also invoked and here the cached values will also be used.

The cache has Maven Search API Request data as a key, so it doesn't matters what document and at what position we're editing. The only requested item types and existing filters are taken into account. So, in theory, we could save and re-use such a cache for a few days, bu this would make it excessively expensive to maintain.