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

[Brian Stansberry]

On 7/31/14, 6:13 PM, Scott Marlow wrote:
> On 07/31/2014 05:02 PM, Paul Ferraro wrote:
>> When did this test start failing?  I suspect it might be related to this commit:
>> https://github.com/wildfly/wildfly/commit/555b8a42249527674448b880b95b334bbdc6ef23
>> If so, I should have a fix for this shortly.
>
> The first failure on brontes was at 07/30/2014 02:03 AM (Brno time?).
> It looks like the above commit was merged around 07/29/2014 11:18 PM
> (EST timezone).
>
> It could be the above commit, I'm not sure.
>

For any test run, click on the "Changes" link and you can often see a 
lot of the recent history of the branch.

In this 2:03 AM run, the commit in question is at the top:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=18974&buildTypeId=WF_8xIgnoreLinux&tab=buildChangesDiv

Seems I shouldn't have merged it.

Some story about a boy shepherd and a wolf comes to mind...

> I tried running the same test against
> 4a765b5d7dee4d28950805c113b0e623fdb017b2 ( WFLY-3486 Make default
> session timeout configurable in the Undertow subsystem) but got a
> "Unable to acquire lock after [15 seconds] on key
> [5f1c2614-2ed8-4b70-951e-f30c9699c8d8] for requestor
> [GlobalTransaction:<null>:105:local]! Lock held by
> [GlobalTransaction:<null>:106:local]
> " error and other exceptions as well.  Not sure why.
>
>>
>> Let's also keep in mind that this isn't really a real-world scenario, as nobody in their right mind would ever set their max-size of the SFSB cache to be so small.
>>
>> So, this is more about getting the test to pass than to fix a functional issue.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat