language server seems to have issues refreshing live data

[martinlippert]

It looks like the language server has issues refreshing live data from Spring Boot 3 applications somehow. Here is what I did (in Eclipse):

• fresh install, fresh workspace, new Rest Service guide complete project, added actuators to the project
• open the GreetingController java source file
• start the project from the boot dashboard

The live hovers show up nicely and correct, but nevertheless the language server shows progress that it tries to refresh live data via several attempts - and shows the failure message at the end of all the retries.

This seem to happen in 4.17.2 as well, but it doesn't seem to happen every single time. Up to now, I haven't figured out the exact circumstances that trigger this behavior though.

[martinlippert]

This shows up on the language server log:

java.lang.Exception: no live data received, lets try again
	at org.springframework.ide.vscode.boot.java.livehover.v2.SpringProcessConnectorOverJMX.refreshGcPausesMetrics(SpringProcessConnectorOverJMX.java:195)
	at org.springframework.ide.vscode.boot.java.livehover.v2.SpringProcessConnectorService.lambda$scheduleRefresh$4(SpringProcessConnectorService.java:246)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

[BoykoAlex]

Okay, I see what this is... I think we sort of knew about this issue all along. It is querying for memory metrics data...

I lack knowledge of how this memory data is being used. I can remove it where i feel necessary. Namely here:
https://github.com/spring-projects/sts4/blob/main/headless-services/spring-boot-language-server/src/main/java/org/springframework/ide/vscode/boot/java/livehover/v2/SpringProcessConnectorService.java#L172 but afraid of breaking downstream vscode extensions

I would remove refresh calls for memory metrics at the connect with hope that whoever wants memory data would attempt to get via the command "sts/livedata/get/metrics" or "sts/livedata/refresh/metrics"

(@vudayani-vmw what do you think?)

I can only reproduce it if I include property:

management.endpoint.metrics.enabled=false

[martinlippert]

Aside from that: why does fetching that data fail?

[BoykoAlex]

My understanding is that there is no data received (InstanceNotAvailableException). Therefore, it attempts to retry fetching the data after a period of time. Looks like there is no way to tell if data is unavailable at the moment or always, therefore a retry.

[martinlippert]

Okay, I think I found the underlying issue: In case there was no GC happening in the running application yet, the jvm.gc.pauses metric is not there yet. This is the reason why we see this failure only sometimes. It depends on whether the JVM of the running app has already executed a GC cycle or not.

So this is not really related to running Spring Boot 2.7x apps vs. Spring Boot 3.0.x. Spring Boot 3.0.x apps are just not triggering GC cycles as early as Spring Boot 2.7.x apps. This is why I stumbled upon this when switching the app to Spring Boot 3.

I think we should take a look at two different things here:

• fix the issue that fetching the GC metrics fails if the metric is not there yet. I think the right approach here is to assume that there is no GC data yet and therefore return an empty result rather than an error.
• fix the issue that the gc and memory metrics are fetched right after starting the app even though no component needs that data. It doesn't make a lot of sense o fetch that data, e.g. in the Eclipse case, since there is no visualization of that data. And even in the VSCode case the dashboard might not be visible or around that uses the metrics data, so we should probably not fetch that data until it is really needed and requested by someone.

Here is a separate issue for the change to not fetch the data after connecting to the running app: #1003. That is scheduled for the 4.18.1 release.

The fix for returning an empty result instead of an exception when there is no GC data yet should be fixed for the 4.18.0 release.

[martinlippert]

Fixed with 6fb6934.

Live data connections do not throw an exception anymore when there are no gc pause metrics yet.