FISH-260 QACI-296: Add diagnostics for missing top-level invocation on stack

[pdudits]

Description

In certain build environment we were hitting following exception:

java.lang.RuntimeException: Exception during processing of event of type AFTER_FILTER_EVENT for web module StandardEngine[glassfish-web].StandardHost[server].StandardContext/1bbf5b4d-c5b2-4d17-90f9-0c21032d50fe
at com.sun.web.server.J2EEInstanceListener.handleAfterEvent(J2EEInstanceListener.java:321)
at com.sun.web.server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java:113)
at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:317)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:260)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:211)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:757)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:182)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:156)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:218)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:524)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.glassfish.api.invocation.InvocationException
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:178)
at com.sun.web.server.J2EEInstanceListener.handleAfterEvent(J2EEInstanceListener.java:317)
... 31 more

The stacktrace reveals two things

• We have no idea what was reason for root InvocationException
• The exception that originally caused invocation to fail was superseded by the invocation exception above

The change adds an explanation to root invocation exception along with ComponentInvocation that the caller expected to be on top. J2EEInstanceListener will pass the original exception as supressed should this situation occur again.

(Un)fortunately, the build started passing after we tried it with these changes, apparently the timing of CI environment changed.

Also included in this change is stability fix for ConcurrentGaugeInterceptorTest, instead of fixed Thread.sleeps it now uses awaitility to poll until expected result is obtained (or timeout).

Testing

Testing Performed

• Build of Payara Micro for testing microprofile-metrics change (the test was unstable on windows)
• Build of related project on Github CI (the condition for FISH-260 was not triggered)

Testing Environment

Windows 10, OpenJDK Runtime Environment (Zulu 8.46.0.19-CA-win64) (build 1.8.0_252-b14), Maven 3.6.3 (QACI-296)
Ubuntu 18.04.4 LTS, AdoptOpenJDK 11 something (not logged), Maven 3.6.3 (FISH-260)

[pdudits]

Jenkins test please

[jbee]

LGTM! Thanks for taking care of the flaky test.