[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]

 From talking with Paul about this situation, it sounds like we 
currently do allow direct passivation of the nested stateful beans, 
without passivating the top level bean that might reference it.

Up to now, I thought that we always passivated the top level stateful 
bean and all referenced beans, as a group.  We actually do passivate the 
entire group (top level + nested beans), when the top level bean is 
passivated but we also allow the nested beans to passivated in an 
isolated fashion.

My question at this point is, could we switch to only passivating top 
level beans?  I'm not sure if we know the difference between top-level 
and nested beans, which might make this difficult or impossible.

On 07/31/2014 11:22 AM, Scott Marlow wrote:
> 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
>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>