What can be the reason for this - The EJB does not exist. session-key: 1907f0100001f-fffffffff78c99c9-135

Technical Discussion
1

Hello,

what can be the reason why the EJBs disappear every now and then? Is there a bug in the EJB management of Glassfish/Payara?

Steven

2

Can you provide the class definition with the annotations of the EJB? And perhaps the beans.xml, if applicable? In which situation is this error thrown?

3

Hello,
here’s an example:

@Stateful
@StatefulTimeout(unit = TimeUnit.HOURS, value = 12)
public class ParentAdministrationImpl extends CommonEntityAdministrationAbstract<ParentEntity> implements ParentAdministration<ParentEntity> {

    private static final Logger LOGGER = LogManager.getLogger(ParentAdministrationImpl.class);

...
    @Override
    public List<String> getInvisibilityFieldNameList(String jsfFileName, String parentId) {
        List<String> invisibleFieldNameList = CommonUtil.createList();
        try {
            Optional<ParentEntity> parent = getParentEntity(jsfFileName, parentId);
            if (parent.isPresent()) {
                parent.get().getInvisibilityEntityList()
                        .forEach(entity -> invisibleFieldNameList.add(entity.getChildComponentId()));
            } else {
                // do nothing
            }
        } catch (Exception e) {
            LOGGER.error(e);
        }
        return invisibleFieldNameList;
    }
...

beans.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                           http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
       version="2.0"
       bean-discovery-mode="all">
</beans>

Exception:

:stackTrace:
javax.ejb.NoSuchEJBException: The EJB does not exist. session-key: 1907f0100001f-1d95f4a-267
at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2394)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2183)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2104)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:90)
at de.huss.mds.ParentAdministration$Serializable$172206067$Proxy$_$$_Weld$EnterpriseProxy$.getInvisibilityFieldNameList(Unknown Source)

This happens once every weeks. I intercept all critical areas with try/catch. I can’t understand what makes Payara do this. There may be a general problem with the EJB management, but it seems to be an exception for me.
It always shows up with other method calls too…

Steven

4

Hi,

sorry for being so late.

The code looks correct.
Ok, here are some more hints, when this exception could be thrown:

  1. Session Timeout:
    Have you checked, if the timeout is reached, that the client also removes the reference and starts a new session?

  2. Explicit Removal:
    Did you have any method annotated with @Remove on the bean

  3. Passivation and Activation Failures:
    Perhaps there is an error during passivation or subsequent activation, such as if the bean or its state is not serializable, the bean might be discarded, and subsequent client calls could result in this exception.

  4. Server Restart or Crash:
    If the server hosting the stateful session bean is restarted or crashes, all in-memory SFSBs are lost. Clients holding references to those beans will encounter this exception upon subsequent calls.

  5. Deployment Issues:
    I think you did not redeploy the bean… but I mention deployment for completeness.

  6. Concurrency Issues:
    If multiple clients or threads access the same stateful session bean instance simultaneously and cause it to be in an inconsistent state, the container might discard the bean instance.

  7. Transaction Rollbacks:
    Some configurations might result in the bean being discarded after a system exception or a transaction rollback, especially if the bean was marked as “Rollback only.”

Perhaps you can check these posdible situations and check also the client code to handle exceptions and get a new instance/session.

1 Like
5

Hello,

i was able to pinpoint the problem and fix it. I only came up with this because my Spring Boot services were behaving strangely as well…
I relied entirely on Oracle’s GraalVM until data. But this causes problems that are not insignificant. Maybe they build a garbage collector that measures and throws away objects that should still be in use, etc. No idea. But since I switched back to the normal OpeneJDK 11, for Payara and the Spring Boot microservices, I haven’t had any strange problems anymore… I think that this will also affect another topic of mine here in the forum, where I constantly… the EJB connections were destroyed even though they shouldn’t have been.

Steven