Is it possible that the EJB lifetime is defined exclusively via the “server-config → EJB Container → EJB Settings → Removal Timeout” parameter?
So far I have defined the session lifetime in my web application via the web.xml, which then begins to expire if no activity of the session is registered. According to the specifications.
<session-config>
<!--Session idle timeout in minutes -->
<session-timeout>60</session-timeout>
</session-config>
Now I’ve noticed that Glassfish ignores this and breaks the EJBs (NoSuchEJBException) if the session (web.xml) hasn’t expired throughout the day because the user is a power user.
The EJB is regenerated after an exception, that’s nice, but the user’s system briefly falls into a state of exception until the EJB is available again in the CDI context.
This problem does not exist with WebLogic 12/14, which I also want to get rid of. Since the EJB’s run as long as the session is active. Stateless and Stateful EJBs may also be created differently, but they are always there or are created in good time.
Can you please provide a simple to follow scenario how to reproduce this on the latest release of Payara Community Edition? A reproducer should ideally follow the SSCCE rules: http://www.sscce.org/.
This will greatly help us to investigate this issue and provide advice or redirect you to the correct channels for bug reports or enhancement requests.
If you require this urgently, consider subscribing to Payara Enterprise which will grant you access to make direct requests to our support engineers.
I have to see if I can reproduce it with a small example.
Will lower the EJB lifetime in Payara myself and see if I can get it reproduced like this.
Of course, I can’t publish the current “very big” project.
Currently I have set “server-config → EJB Container → EJB Settings → Removal Timeout” to several hours and under “EJB Timer Service → Persistence Service” to DataGrid. No more errors in the big project for several days.
Example error:
Error:javax.ejb.NoSuchEJBException
The EJB does not exist. session key: 1907f0100001f-7f7beb0b-0
javax.ejb.NoSuchEJBException: The EJB does not exist. session key: 1907f0100001f-7f7beb0b-0
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)
…
Cannot load from BACKUPSTORE FOR Key: <[1907f0100001f-7f7beb0b-0]
Cannot load from BACKUPSTORE FOR Key means exactly?
I haven’t been able to write any reproducible code for it yet, as it keeps popping up sporadically in our software and I haven’t found a way to do it, other than setting the “Removal Timeout” option to 10 seconds, and then it pops up more often.
Is it possible that an error occurs when reading the memory to get the stateful EJB back (ejbLoad())?
I would also be interested to know whether the Enterprise Edition, which we would like to switch to, behaves differently, but only if I see that Payara Community is running stably.
Is it possible a runtime exception is thrown in your code which is causing the EJB to be destroyed? If you aren’t able to consistently reproduce this bug, I would recommend you check the server logs after this error occurs to try and identify patterns in this behaviour. Knowing more about this issue and its causes would greatly help us investigate this issue.
If you have a reproducer which is able to inconsistently but still somewhat frequently cause this error, I would invite you to share it for me to take a further look into the problem.
As a reminder, Payara Community is focused on innovation whereas Payara Enterprise is focused on stability. A Payara Enterprise subscription would also allow you to raise tickets to our support engineers who can have an in-depth investigation into your issue.
Because Payara complains again that he didn’t find the stateful bean xyz with session-key xyz… I know you need an example and it’s my turn to provide a reproducible example.
The Cannot load from BACKUPSTORE FOR Key error message is caused when the EJB Container didn’t find the data related with the given session key. I still suspect this is caused by a runtime exception causing the EJB to be destroyed, which therefore means data can’t be found for that session and the stateful bean xyz can’t be found (as it was destroyed).
As you said, a reproducible example would help confirm my suspicion or reveal a different cause.
Just to follow up with some more potentially useful information for you, the EJB Thread Pool can be configured and may show a difference between your WebLogic installation and Payara installation. Documentation on configuring the EJB Thread Pool can be found here which might be useful for you: EJB Thread Pool :: Payara Enterprise Documentation
