Awesome. I guess folks are working on fixing these? On 11 Oct 2012, at 17:12, Sanne Grinovero <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Manik Surtani >> [email protected] >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
