Fixes in monitoring, enable monitoring in Embedded GlassFish

[OndroMih]

Ensures that the reported current thread count and busy thread count is exactly the number of threads reported by the pool. Even if monitoring is started while thread pool is actively processing requests.

A few improvements in Embedded GlassFish to enable monitoring and access it via JMX (it was completely broken before):

• if the flashlight-agent is already loaded, don't attempt to load it - that would fail on newer Java versions
• concatenate probe-provider-class-names MANIFEST elements from dependencies, using gmaven plugin script at build time. It references all probes that should be activated

Embedded GlassFish requires running with flashlight-agent on command line with -javaagent:flashlight-agent.jar on newer Java versions as it doesn't contain the agent. Dynamic loading of agent is not a good practice with newer Java versions anyway.

When started with command "enable-monitoring --mbean true", metric will be available via JMX beans:

Example to start Embedded GlassFish with thread pool and http service metrics:

java -javaagent:/path/to/flashlight-agent.jar -jar glassfish-embedded-all.jar 'enable-monitoring --modules thread-pool:http-service'

Or, alternatively, using the following properties in glassfish.properties in the current directory:

configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH

And command:

java -javaagent:/path/to/flashlight-agent.jar -jar glassfish-embedded-all.jar

Then in VisualVM (with MBeans extension), in the amx node:

If you don't see the amx node, you need to execute the bootAMX operation from VisualVM first (the added test demonstrates how to do that in code):

[pzygielo]

Is this required, unlike in other workflows?

[dmatej]

First idea was that the windows container is so slow, so Ondro tried to find some solution to improve its performance using ram disks etc. Now I am slowly fixing some problematic code pieces and adding logs to find out why the execution just times out after several hours and just with Windows GHA container.
I will try to run that yet on Windws Server 25 in VirtualBox for sure, because this is really awful behavior, looks like some black hole network communication.

[pzygielo]

My question is for

permissions:
  checks: write

I've seen commit with that setting being removed (undone) from other workflow files, but it's still in linux one.

[OndroMih]

I think @dmatej you reverted too much in this commit: 3fb9a43

I added

permissions:
  checks: write

for the action-junit-report step, although I added it with a commit that only mentions adding RAM disk. Though it seems that have this permission block doesn't have any effect.

I don't understand how the action-junit-report exactly works. Now I tried to enable annotation-only mode, hopefully it will provide us what I seek for - information about which tests fail if some tests fail. Right now, this step only provides the number of passed and failed tests.

[dmatej]

It is a work in progress, I will go over those commits later one by one and move some changes to own PR. First I need to understand what is really happening and why the build freezes just on GHA.

[dmatej]

Status: I have rebased #25768 to this, fixed conflicts (I made them). Now I will create another PR just with Ondro's changes in GHA, then I will rebase again, I will try yet to improve the performance of those new tests in application-tests, so we could avoid those tags. I have a new weapon for that, learned new usages of the Stream API :-)

Otherwise, nothing new about Jenkins performance, unfortunately.