@Stateful EJB issues when migrating to Wildfly 31 and Jakarta EE 10

[Susanne Jarl]

Hi,

I'm migrating from java ee8 to jakarta ee 10 and from Wildfly 26 to 31. The web application runs fine on localhost but when I put it in production with a lot of users I get a lot of exceptions and they all seem to have something to do with my @Stateful EJBs not behaving as aspected.

Error message 1: 

 org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean:  Session bean [class PostBean with qualifiers [@Default @Any @Named]; local interfaces are [PostBean]
  Proxy: class recepten.view.core.PostBean$Proxy$_$$_Weld$EnterpriseProxy$

Caused by: jakarta.ejb.EJBException: java.lang.NullPointerException: Cannot invoke "jakarta.servlet.http.HttpSession.getAttribute(String)" because "session" is null

Error message 2:

2024-03-28 17:56:23,887 ERROR [org.jboss.as.ejb3.invocation] (default task-79) WFLYEJB0034: Jakarta Enterprise Beans Invocation failed on component NavigationBean for method public java.lang.String .NavigationBean.getUrlId(): jakarta.ejb.EJBTransactionRolledbackException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  

Error message 3:

This only happens during startup of the server and then I get this:

jakarta.ejb.EJBTransactionRolledbackException: jakarta.transaction.RollbackException: ARJUNA016053: Could not commit transaction. Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint

and this bean is just reading from the database. (And nowhere in my code I'm inserting anything in that table.) What is funny is that I remember I got this error message many years ago on a previous wildfly or jboss and I got rid of it by upgrading to a later version. 

If I browse my website many times, sometimes the pages shows correctly and sometimes I just get a blank page. And the server log just get filled up with exceptions since I today had about 1000 simultaneous users on the site.

Remember this only happens in production. And when I run locally everything works perfectly.

It seems that the SFSB doesn't get cleaned up properly?

My question is if there is something I can do about it? Has something changed from Wildfly 26 to 31? Am I suppose to change something in standalone.xml (this isn't necessary on wildfly 26) in order to improve performance? 

Or is this perhaps a bug in Wildfly 31.0.1?

Thanks in advance for taking your time to answer this!

/Susanne

[Scott Marlow]

Hi,

For error 2, what is the value shown in the "persistence context already in transaction =" part of that error? 

When you run the application locally, are you simulating the load of many (web) users or are you the only user?

Scott

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d040fcb3-0398-4bc0-bec6-946d5c12ac3cn%40googlegroups.com.

[Susanne Jarl]

Hi,

Thanks for answering!

persistence context already in transaction =ExtendedEntityManager

Please tell me if you want more error messages, stacktrace etc.

All my SFSB looks like this:

@Named
@RequestScoped
@Stateful

with

@PersistenceContext(type = PersistenceContextType.EXTENDED)

for those that has their own EntityManager. Some SFSB inject other SFSB.

When I run on localhost it is just me and no simulation of load. 

All the SFSB are @RequestScoped. No logged in users. 

While doing the migration I have not made any other changes in the code because it's obviously best to make changes in small steps. It is almost only the javax -> jakarta namespace change that was made in the SFSBs. All my code before migration worked fine on Java EE 8 and Wildfly 26 with the same heavy load in production and I use standard configuration in standalone.xml.

Thanks,

Susanne

[Susanne Jarl]

Hi,

Actually I managed to solve 1 and 2 now and since 3 only shows up during startup it is not a show stopper, only annoying.

ErrorMessage 1: Problem was that I injected a SessionScoped Object (a logged in User) in my RequestScoped SFSB. And that's why I got the errorMessage that "session" is null. 

ErrorMessage 2: I removed @Stateful from my NavigationBean. I didn't need the features of it anyway since it's basically just a POJO. Although I don't understand why it can't be a SFSB. Maybe because I use it to put in my JSF ViewParameters?

ErrorMessage 3: Still there. Guess there are some more things to fix in my code. Any ideas, please tell me. It annoys me even though it just shows up during startup of the server and only in production with at least some load. I guess there are some old SFSB hanging around that it tries to passivate and then try to save the state of and then tries to insert things in my database? This is strange behaviour.

Over all it would be helpful with better error messages. And also I find it strange I didn't get those error messages when running on localhost (just me). Obviously I did some bad things in my code that was acceptable in Java EE8 / Wildfly 26 but now I clearly got punished for it in Jakarta EE10 / Wildfly 31. ;-)

Thanks,

Susanne

[Scott Marlow]

On 3/30/24 05:17, Susanne Jarl wrote:

Hi,

Actually I managed to solve 1 and 2 now and since 3 only shows up during startup it is not a show stopper, only annoying.

ErrorMessage 1: Problem was that I injected a SessionScoped Object (a logged in User) in my RequestScoped SFSB. And that's why I got the errorMessage that "session" is null. 

ErrorMessage 2: I removed @Stateful from my NavigationBean. I didn't need the features of it anyway since it's basically just a POJO. Although I don't understand why it can't be a SFSB. Maybe because I use it to put in my JSF ViewParameters?

It sounds like removing @Stateful helped avoid the error since extended persistence context are only supported in @Stateful bean.  Meaning that the persistence context is now treated as a transaction scoped persistence context which avoids the previously thrown WFLYEJB0034 error.  In terms of whether the throwing of the WFLYEJB0034 error is a bug or not, I think that would be an interesting question to explore.  

Do you happen to know if the previously mentioned "persistence context already in transaction =ExtendedEntityManager" bean was in the current call stack?  I will call that bean, the unknown bean for now.  Or was the previous call to the unknown bean done within the same active (JTA) transaction and the call to a unknown bean method had completed before the call to the NavigationBean?

To summarize the possibilities:

A.  An unknown bean method was first called and the unknown bean method then called the NavigationBean method which threw the error.

B.  An unknown bean method was first called and the unknown bean method returned to the caller.  The caller than then called the NavigationBean method which threw the error.

I hope that ^ makes sense.

ErrorMessage 3: Still there. Guess there are some more things to fix in my code. Any ideas, please tell me. It annoys me even though it just shows up during startup of the server and only in production with at least some load. I guess there are some old SFSB hanging around that it tries to passivate and then try to save the state of and then tries to insert things in my database? This is strange behaviour.

If you get this locally on your machine, you could turn on TRACE logging for org.hibernate category and org.jboss.as.jpa which should help identify the part of your application that influences the unexpected insert to happen.  https://docs.wildfly.org/31/Developer_Guide.html#troubleshooting has more details about enabling TRACE logging.  

Thanks,
Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/76aaa42b-3089-4ef8-8390-fdd9dd468220n%40googlegroups.com.

[Scott Marlow]

On 4/1/24 10:00, Scott Marlow wrote:

On 3/30/24 05:17, Susanne Jarl wrote:

Hi,

Actually I managed to solve 1 and 2 now and since 3 only shows up during startup it is not a show stopper, only annoying.

ErrorMessage 1: Problem was that I injected a SessionScoped Object (a logged in User) in my RequestScoped SFSB. And that's why I got the errorMessage that "session" is null. 

ErrorMessage 2: I removed @Stateful from my NavigationBean. I didn't need the features of it anyway since it's basically just a POJO. Although I don't understand why it can't be a SFSB. Maybe because I use it to put in my JSF ViewParameters?

It sounds like removing @Stateful helped avoid the error since extended persistence context are only supported in @Stateful bean.  Meaning that the persistence context is now treated as a transaction scoped persistence context which avoids the previously thrown WFLYEJB0034 error.  In terms of whether the throwing of the WFLYEJB0034 error is a bug or not, I think that would be an interesting question to explore.  

Do you happen to know if the previously mentioned "persistence context already in transaction =ExtendedEntityManager" bean was in the current call stack?  I will call that bean, the unknown bean for now.  Or was the previous call to the unknown bean done within the same active (JTA) transaction and the call to a unknown bean method had completed before the call to the NavigationBean?

To summarize the possibilities:

A.  An unknown bean method was first called and the unknown bean method then called the NavigationBean method which threw the error.

B.  An unknown bean method was first called and the unknown bean method returned to the caller.  The caller than then called the NavigationBean method which threw the error.

I will make a few more assumptions now.  Since the default WildFly configuration standalone.xml contains the following, I will assume that possibility (B) is what we experienced for the mentioned failure:

"
       <subsystem xmlns="urn:jboss:domain:jpa:1.1">
           <jpa default-extended-persistence-inheritance="DEEP"/>
       </subsystem>
"

If you happen to be using <jpa default-extended-persistence-inheritance="SHALLOW"/, please let me know that as well.

I think that we should create a https://issues.redhat.com/browse/WFLY issue requesting an enhancement request to allow extended persistence contexts (XPC) to be able to share the XPC joined to the current active JTA transaction which I think would of avoided the error message 2 (WFLYJPA0030).

Let me know if you can create a https://issues.redhat.com/browse/WFLY for ^.

Thanks,
Scott

[Susanne Jarl]

Hi,

NavigationBean is first called since it is requested first in the metadata in my jsf. The ”unknown bean” is ”myBean” and this is how it looks in my JSF:

<f:metadata>
    <o:viewParam name="urlId" value="#{navigationBean.urlId}" />
    <o:viewAction action=”#{myBean.find()}" onPostback="true" />
</f:metadata>

The NavigationBean is just a POJO.  In MyBean, NavigationBean is injected. The method ”find()” uses the urlId from navigationBean to lookup content in the database and therefore needs EntityManager. MyBean is a SFSB.

So I guess neither A or B applies? Any ideas?

In standalone.xml I haven’t made any changes, I use the default which is DEEP.

/Susanne

[Susanne Jarl]

ErrorMessage 3: Still there. Guess there are some more things to fix in my code. Any ideas, please tell me. It annoys me even though it just shows up during startup of the server and only in production with at least some load. I guess there are some old SFSB hanging around that it tries to passivate and then try to save the state of and then tries to insert things in my database? This is strange behaviour.

If you get this locally on your machine, you could turn on TRACE logging for org.hibernate category and org.jboss.as.jpa which should help identify the part of your application that influences the unexpected insert to happen.  https://docs.wildfly.org/31/Developer_Guide.html#troubleshooting has more details about enabling TRACE logging.  

The problem is that this error only appears in production with some load. I would be nice to solve this problem as well. 

/S