[infinispan-dev] Infinispan Large Scale support

[Bela Ban]

I'd also suggest JGroups 2.12.0.Final, not sure if Infinispan 4.2.1.CR4 
ships with it...

On 3/18/11 5:25 PM, david marion wrote:
>
>
>    I will see if I can get 4.2.1.CR4 uploaded onto the system. Is there a reference to the system property in question?
>
>
>
> From: manik at jboss.org
> Date: Fri, 18 Mar 2011 16:07:06 +0000
> To: infinispan-dev at lists.jboss.org
> Subject: Re: [infinispan-dev] Infinispan Large Scale support
>
>
>
>
>
> On 18 Mar 2011, at 15:45, david marion wrote:
>
> Bela,
>
>    Agreed, increasing the timeouts is probably not the way to go. However I am at the mercy of whatever Infinispan is doing. As for the notion of Infinispan being tested at 1000 nodes:
>
>    Manik was quoted here: http://itmanagement.earthweb.com/netsys/article.php/3864436/Red-Hat-Ramps-Up-Open-Source-Cloud-Projects.htm
>
>
>
> Yeah, we got a hold of an 1100 node cluster to test on at that time.  But that cluster proved unstable and kept falling over with network issues.
>
>
>    It was never denied here: http://community.jboss.org/thread/156494?tstart=0
>    and I'll have to wait until I get home to dig up an email that I think I have.
>
> However, I'm not assigning blame, I was under the impression that it had been tested at 1000 nodes. I just had it up at 430 nodes, but I can't reliably get it to that size when I restart it. I think the answer is that Infinispan will have to use what will scale in JGroups (remove what does not scale). Until then I will have to scale it down to a size that I can start in a reliable fashion.
>
>    Still no answer on whether ISPN-83 will be in 4.2.1.....
>
>
>
> See my response earlier on this thread about this.
>
>
> Specifically, Infinispan throws a config exception if FLUSH is *not* present.  However, we did cut a release without this check and ran our defaults without FLUSH.  It worked well enough for most people, except one important use case.  And this is what needs further investigation.  It seems as though the problem with that use case was not the removal of FLUSH, but some dependence in the test in question on FLUSH.  But it's too late in the 4.2.1 cycle to pull something like this, hence my proposal to leave FLUSH in by default but to allow a FLUSH-free config via a (temporary, 4.2.x only) system property while we investigate properly removing FLUSH in 5.0.
>
>
> Cheers
> Manik
>
>
> --
>
>
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
>
> Lead, Infinispan
> http://www.infinispan.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

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss