As established by the EJB spec, the access timeout for an EJB locked for access on concurrency management can be set via @AccessTimeout annotation.
Without this annotation specifying otherwise, the timeout in Payara for accessing a locked EJB is infinite.
This is pretty inconvenient because it generates no stack or log traces whatsoever on the application server log during a deadlock. It just hangs the dependent services, making them unresponsive.
Our team wants to modify this default in our development server, to have the beans throw a jakarta.ejb.ConcurrentAccessException every time a bean or bean method is locked for access for a longer time than it should.
I know from working with JBoss/Wildfly back in the day that this should be possible via application server configuration. We have not been able to find related documentation to do this for Payara/Glassfish asadmin, though.
Is there a way to set a default concurrent EJB access timeout on Payara? If not, what would be a viable alternative to easily identify deadlocks as they happen in our development server?
Apparently there's this nice Payara cdi-event-bus-notifier we could set up to collect metrics on hogging & stuck threads, which we could then set alerts on:
https://blog.payara.fish/the-health-check-service-in-depth-payara-server
This would satisfy the needs for our use case even better than setting a default access timeout (e.g. we could even enable it on production, eventually).
Nevertheless it would be nice to know if there is a possibility to set a default access timeout (which, for example, could allow us to more conveniently look at the server logs rather than the metrics when working on a local dev deployment).