Regarding ISPN-1786, I'd like to work with Sanne/Mircea on trying out the new UNICAST2. In my local tests, I got a 15% speedup, but this is JGroups only, so I'm not sure how big the impact would be on Infinispan. If we see a big speedup, UNICAST2 and NAKACK2 could then be backported to a 3.0.4, and added to 5.1.1. However, I want to spend some time on testing UNICAST2, so this won't be available tomorrow... On 1/26/12 11:42 PM, Manik Surtani wrote: > I really didn't want to do this, but it looks like a 5.1.1 will be necessary. The biggest (critical, IMO, for 5.1.1) issues I see are: > > 1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to do with a bug Mircea spotted that virtual nodes were not being enabled by the config parser. Which meant that even in the case of tests enabling virtual nodes, we still saw uneven distribution and hence poor performance (well spotted, Mircea). > 2. Related to 1, I don't think there is a JIRA for this yet, to change the default number of virtual nodes from 1 to 100 or so. After we profile and analyse the impact of enabling this by default. I'm particularly concerned about (a) memory footprint and (b) effects on Hot Rod relaying topology information back to clients. Maybe 10 is a more sane default as a result. > 3. https://issues.jboss.org/browse/ISPN-1788 - config parser out of sync with XSD! > 4. https://issues.jboss.org/browse/ISPN-1798 - forceReturnValues parameter in the RemoteCacheManager.getCache() method is ignored! > > In addition, we may as well have these "nice to have's" in as well: > > https://issues.jboss.org/browse/ISPN-1787 > https://issues.jboss.org/browse/ISPN-1793 > https://issues.jboss.org/browse/ISPN-1795 > https://issues.jboss.org/browse/ISPN-1789 > https://issues.jboss.org/browse/ISPN-1784 > > What do you think? Anything else you feel that is crucial for a 5.1.1? I'd like to do this sooner rather than later, so we can still focus on 5.2.0. So please respond asap. > > Paul, I'd also like your thoughts on this from an AS7 perspective. > > Cheers > Manik > > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Bela Ban Lead JGroups (http://www.jgroups.org) JBoss / Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 27 Jan 2012, at 07:03, Bela Ban wrote: > Regarding ISPN-1786, I'd like to work with Sanne/Mircea on trying out > the new UNICAST2. In my local tests, I got a 15% speedup, but this is > JGroups only, so I'm not sure how big the impact would be on Infinispan. nice! I can trigger a radargun run very quickly, just let me know the branch. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

There's an initialisation error indicating a dependency on a test class[1]. Seems like jgroups is not jar-less anymore :-) [1] at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:236) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java :875) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:630) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:619) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:523) at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:200) ... 12 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:234) ... 17 more Caused by: java.lang.ExceptionInInitializerError at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:57) at org.jgroups.stack.Protocol.<init>(Protocol.java:57) at org.jgroups.stack.ProtocolStack.<init>(ProtocolStack.java:144) at org.jgroups.JChannel.init(JChannel.java:793) at org.jgroups.JChannel.<init>(JChannel.java:167) at org.jgroups.JChannel.<init>(JChannel.java:137) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:327) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:250) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:290) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:168) ... 22 more Caused by: java.lang.ClassNotFoundException: org.jgroups.tests.perf.MPerf$MPerfHeader at org.jgroups.util.Util.loadClass(Util.java:2661) at org.jgroups.conf.ClassConfigurator.init(ClassConfigurator.java:84) at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:54) ... 31 more On 27 Jan 2012, at 14:24, Bela Ban wrote: > The branch is JGRP-1417 and the config for UNICAST2 is: > > <UNICAST2 > max_bytes="20M" > xmit_table_num_rows="20" > xmit_table_msgs_per_row="10000" > xmit_table_max_compaction_time="10000" > max_msg_batch_size="100"/> > > I've attached the config I've used for UPerf. > > Cheers, > > > > > On 1/27/12 3:12 PM, Mircea Markus wrote: >> On 27 Jan 2012, at 07:03, Bela Ban wrote: >>> Regarding ISPN-1786, I'd like to work with Sanne/Mircea on trying out >>> the new UNICAST2. In my local tests, I got a 15% speedup, but this is >>> JGroups only, so I'm not sure how big the impact would be on Infinispan. >> >> nice! I can trigger a radargun run very quickly, just let me know the branch. >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Bela Ban > Lead JGroups (http://www.jgroups.org) > JBoss / Red Hat > <fast.xml>_______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 27 Jan 2012, at 15:08, Bela Ban wrote: > Build the JGroups JAR with ./build.sh jar, *not* via maven ! > > I attached the JAR for you. Thanks! > JGroups *is* and *will remain* JAR less ! :-) Sorry for loosing the faith :) Might make sense to have the mvn install work as well though, I think people would expect it to behave correctly when they see a pom.xml.

I really didn't want to do this, but it looks like a 5.1.1 will be necessary. The biggest (critical, IMO, for 5.1.1) issues I see are: 1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to do with a bug Mircea spotted that virtual nodes were not being enabled by the config parser. Which meant that even in the case of tests enabling virtual nodes, we still saw uneven distribution and hence poor performance (well spotted, Mircea). 2. Related to 1, I don't think there is a JIRA for this yet, to change the default number of virtual nodes from 1 to 100 or so. After we profile and analyse the impact of enabling this by default. I'm particularly concerned about (a) memory footprint and (b) effects on Hot Rod relaying topology information back to clients. Maybe 10 is a more sane default as a result.

3. https://issues.jboss.org/browse/ISPN-1788 - config parser out of sync with XSD! 4. https://issues.jboss.org/browse/ISPN-1798 - forceReturnValues parameter in the RemoteCacheManager.getCache() method is ignored!

In addition, we may as well have these "nice to have's" in as well: https://issues.jboss.org/browse/ISPN-1787 https://issues.jboss.org/browse/ISPN-1793 https://issues.jboss.org/browse/ISPN-1795

https://issues.jboss.org/browse/ISPN-1789

https://issues.jboss.org/browse/ISPN-1784

What do you think? Anything else you feel that is crucial for a 5.1.1? I'd like to do this sooner rather than later, so we can still focus on 5.2.0. So please respond asap.

On 27 Jan 2012, at 14:09, Mircea Markus wrote: > > On 26 Jan 2012, at 22:42, Manik Surtani wrote: >> I really didn't want to do this, but it looks like a 5.1.1 will be necessary. The biggest (critical, IMO, for 5.1.1) issues I see are: >> >> 1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to do with a bug Mircea spotted that virtual nodes were not being enabled by the config parser. Which meant that even in the case of tests enabling virtual nodes, we still saw uneven distribution and hence poor performance (well spotted, Mircea). >> 2. Related to 1, I don't think there is a JIRA for this yet, to change the default number of virtual nodes from 1 to 100 or so. After we profile and analyse the impact of enabling this by default. I'm particularly concerned about (a) memory footprint and (b) effects on Hot Rod relaying topology information back to clients. Maybe 10 is a more sane default as a result. > > There is one now: https://issues.jboss.org/browse/ISPN-1801 > >> 3. https://issues.jboss.org/browse/ISPN-1788 - config parser out of sync with XSD! >> 4. https://issues.jboss.org/browse/ISPN-1798 - forceReturnValues parameter in the RemoteCacheManager.getCache() method is ignored! > > I'm sure there will some others as community starts reporting! but that's good as we can provide a quick release for the main issues. > >> In addition, we may as well have these "nice to have's" in as well: >> >> https://issues.jboss.org/browse/ISPN-1787 >> https://issues.jboss.org/browse/ISPN-1793 >> https://issues.jboss.org/browse/ISPN-1795 > > these ^^ are already in master so we can include them straight away. >> https://issues.jboss.org/browse/ISPN-1789 > > this looks like a low prio, as doesn't have an impact on the functionality Agreed, but it is such a trivial fix and it greatly affects usability (who wants to see such verbose and misleading log messages?) > >> https://issues.jboss.org/browse/ISPN-1784 > pull request sent, so IMO makes sense. >> >> What do you think? Anything else you feel that is crucial for a 5.1.1? I'd like to do this sooner rather than later, so we can still focus on 5.2.0. So please respond asap. > As everybody is in the performance min set, I think the following issues, in this order, would be a quick win: > https://issues.jboss.org/browse/ISPN-825 > https://issues.jboss.org/browse/ISPN-317 > https://issues.jboss.org/browse/ISPN-1748 -1 to all 3. I think these are all non-trivial and shouldn't be in a point release - even if it is a week's worth of work. Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I really didn't want to do this, but it looks like a 5.1.1 will be necessary. The biggest (critical, IMO, for 5.1.1) issues I see are: 1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to do with a bug Mircea spotted that virtual nodes were not being enabled by the config parser. Which meant that even in the case of tests enabling virtual nodes, we still saw uneven distribution and hence poor performance (well spotted, Mircea). 2. Related to 1, I don't think there is a JIRA for this yet, to change the default number of virtual nodes from 1 to 100 or so. After we profile and analyse the impact of enabling this by default. I'm particularly concerned about (a) memory footprint and (b) effects on Hot Rod relaying topology information back to clients. Maybe 10 is a more sane default as a result. 3. https://issues.jboss.org/browse/ISPN-1788 - config parser out of sync with XSD! 4. https://issues.jboss.org/browse/ISPN-1798 - forceReturnValues parameter in the RemoteCacheManager.getCache() method is ignored! In addition, we may as well have these "nice to have's" in as well: https://issues.jboss.org/browse/ISPN-1787 https://issues.jboss.org/browse/ISPN-1793 https://issues.jboss.org/browse/ISPN-1795 https://issues.jboss.org/browse/ISPN-1789 https://issues.jboss.org/browse/ISPN-1784 What do you think? Anything else you feel that is crucial for a 5.1.1? I'd like to do this sooner rather than later, so we can still focus on 5.2.0. So please respond asap. Paul, I'd also like your thoughts on this from an AS7 perspective.

Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 28 Jan 2012, at 19:33, Paul Ferraro wrote: > It would be nice to see those few minor issues that I raised post-FINAL, > specifically the xsd update and removing some of those startup WARNings. Yes, that is definitely on the cards for 5.1.1. > I'm also chasing down a issue that we're seeing occasionally on our test > runs where we're attempting to perform a cache operation from a > @ViewChanged event which occasionally causes a flurry of "Failed to > prepare view CacheView" due to a > org.infinispan.remoting.transport.jgroups.SuspectException. This is > definitely something that we need to figure out ASAP. I'm not sure yet > if this is an Infinispan problem or whether I'm trying to do something > stupid. I've opened ISPN-1806 just in case. I saw that you've closed ISPN-1806 again? Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Sun, 2012-01-29 at 04:49 -0500, Manik Surtani wrote: > Also, Paul, what are your thoughts around timing for a 5.1.1.CR1 > and .FINAL? AS7.1 is due to be released Feb 8th. 5.1.1 would need to happen extremely quickly (i.e. this week).