NPE on PoolManagerImpl.resourceClosed(PoolManagerImpl.java:367)

[escay]

Environment Details

• GlassFish Version (and build number): 7.0.10
• JDK version: jdk-17.0.8.1_1-openjdk-adoptium
• OS: Windows 10
• Database: Postgresql

Problem Description

[#|2024-03-04T10:54:56.452677+01:00|WARNING|GF 7.0.10|jakarta.enterprise.web.vs.server|_ThreadID=80;_ThreadName=http-listener-1(5);_LevelValue=900;|
  StandardWrapperValve[com.netinium.test.rest.RESTConfiguration]: Servlet.service() for servlet com.netinium.test.rest.RESTConfiguration threw exception
java.lang.IllegalStateException: state.isBusy() : false
        at com.sun.enterprise.resource.pool.ConnectionPool.resourceClosed(ConnectionPool.java:978)
        at com.sun.enterprise.resource.pool.PoolManagerImpl.putbackResourceToPool(PoolManagerImpl.java:414)
        at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:368)
        at com.sun.enterprise.resource.listener.LocalTxConnectionEventListener.connectionClosed(LocalTxConnectionEventListener.java:71)
        at com.sun.gjc.spi.ManagedConnectionImpl.connectionClosed(ManagedConnectionImpl.java:735)
        at com.sun.gjc.spi.base.ConnectionHolder.close(ConnectionHolder.java:193)
        at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:590)
        at com.mycompany.database.firmware.dbbase.FirmwareFileDbBase.selectFirmwareFileValue(FirmwareFileDbBase.java:188)

which was also seen in my logged Payara issue:
payara/Payara#3029

and now I also observed again as part of my investigation of Glassfish #24805

Steps to reproduce

Difficult, see #24805, suspecting resource handles to be 'compromised'.

Impact of issue

Incorrect cleanup of resources, and long stacktraces
While expecting at least to cleanup the resource, even if state is incorrect and log a warning instead of throwing an exception.

I plan to add a similar fix as done in Payara in the past: payara/Payara@f1cbfc0

• Log the item and no longer fail with an exception, but let the method finish gracefully.
  Like:

        if (!state.isBusy()) {
            // Do not throw exception, the current transaction should not fail if the state is incorrect.
            // This method is for example also called from putbackBadResourceToPool
            // throw new IllegalStateException("state.isBusy() : false");
            LOG.log(WARNING, "resourceClosed - Expecting 'state.isBusy() : false', but was true for handle: " + handle);
        }