[wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans...

[Scott Marlow]

Just to keep everyone in the loop, it seems like configuring the 
passivation max-size to be less than "one + number of nested beans", 
could be the cause.  We are currently configuring the passivation cache 
max-size to be one, which may lead to passivation of the nested bean.

In the PassivationTestCase test, each top level session bean has a 
nested bean.  The top level bean shares the extended persistence context 
with the nested bean.

If users hit this same failure, they should ensure that max-size is at 
least equal to "1 + number of nested beans referenced from top level bean".

We will continue to discuss this case on IRC or email and keep you all 
posted.

Scott

On 07/31/2014 05:52 AM, Tomaž Cerar wrote:
> For time beeing I have muted and assigned this test failure on brontes
> to you Scott.
>
> This way people wont get bogus PR test failures while you are working on
> a fix.
>
> --
> tomaz
>
>
> On Thu, Jul 31, 2014 at 4:18 AM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     We started to see what looks like a JPA extended persistence context
>     related error.  [1] is the server.log that shows the exception (see the
>     last one near the bottom) that shouldn't be happening on WildFly master.
>        Also, there are some marshalling errors that I didn't see on brontes
>     (I'm wondering if there is a concurrency error between the bean
>     invocation and passivation/activation when Hibernate throws the
>     "java.lang.IllegalStateException: Cannot serialize a session while
>     connected" error during marshalling as if bean is active).
>
>     I am able to recreate the failure locally with a modification to the
>     PassivationTestCase.testPassivationMaxSize() [2] to repeatedly
>     alternative between calls to remote1 + remote2 beans.
>
>     I don't have this nailed down to the actual cause but it seems like a
>     race condition between passivation/activation and bean invocation (imo).
>
>     Scott
>
>     [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the
>     results from more than one test run.  If you look at the server.log, you
>     probably should go to the end and see the last "javax.ejb.EJBException:
>     WFLYJPA0030: Found extended persistence context in SFSB invocation call
>     stack but that cannot be used" error
>
>     [2] unit test change to loop repeatedly until failure occurs
>     https://github.com/scottmarlow/wildfly/tree/passivationxpcissue
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>