[infinispan-dev] Hung testsuite
Manik Surtani
manik at jboss.org
Thu Oct 11 13:29:09 EDT 2012
Awesome. I guess folks are working on fixing these?
On 11 Oct 2012, at 17:12, Sanne Grinovero <sanne at infinispan.org> wrote:
> Yes thanks! the tests don't deadlock anymore, they just fail consistently:
>
> Failed tests:
> testForceCommitXid(org.infinispan.tx.recovery.admin.SimpleCacheRecoveryAdminTest):
> expected:<false> but was:<true>
> timeBasedTakeOffline(org.infinispan.xsite.offline.OfflineStatusTest):
> expected:<false> but was:<true>
> indexWasStored(org.infinispan.loaders.decorators.BatchAsyncCacheStoreTest):
> expected:<false> but was:<true>
> testTwoNamedCachesSameNode(org.infinispan.tx.TransactionsSpanningDistributedCachesTest):
> Timed out waiting for rebalancing to complete on node
> TransactionsSpanningDistributedCachesTest-NodeS-50037, expected member
> list is [TransactionsSpanningDistributedCachesTest-NodeS-50037,
> TransactionsSpanningDistributedCachesTest-NodeT-374], current member
> list is [TransactionsSpanningDistributedCachesTest-NodeS-50037]!
>
> Tests run: 1640, Failures: 4, Errors: 0, Skipped: 0
>
> Not perfect, but a nice progress.
>
> Cheers,
> Sanne
>
>
> On 11 October 2012 12:47, Manik Surtani <manik at jboss.org> wrote:
>> Sanne, does this fix the test suite for you? For whatever reason, this
>> issue appears on your machine more often than anyone else's … :)
>>
>> On 3 Oct 2012, at 12:56, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> Thanks for the workaround, Bela!
>> I've included it in https://github.com/infinispan/infinispan/pull/1358.
>>
>>
>> On Wed, Oct 3, 2012 at 9:32 AM, Bela Ban <bban at redhat.com> wrote:
>>>
>>>
>>>
>>> On 10/2/12 6:02 PM, Dan Berindei wrote:
>>>
>>>>> The members should be updated in viewAccepted(). When you connect a
>>>>> channel, then viewAccepted() will be called *before* JChannel.connect()
>>>>> returns, so the main thread won't have a chance of accessing members
>>>>> before that.
>>>>>
>>>>>
>>>> Ok, if viewAccepted() is guaranteed to be called before connect()
>>>> returns
>>>> then you're right, the latch is superfluous. We only need to call
>>>> viewAccepted() ourselves if the channel was injected (which we already
>>>> do).
>>>>
>>>> In this particular case, however, we don't get a viewAccepted() call or
>>>> an
>>>> exception from connect(), so I'm not sure it would have been better
>>>> (easier
>>>> to debug) without the latch.
>>>
>>>
>>> This is due to https://issues.jboss.org/browse/JGRP-1522, which was
>>> introduced in 3.2.0; when this is fixed, you will get a viewAccepted().
>>> The workaround is to set NAKACK{2}.become_server_queue_size=0.
>>>
>>> --
>>> Bela Ban, JGroups lead (http://www.jgroups.org)
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>>
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121011/f3585307/attachment.html
More information about the infinispan-dev
mailing list