On 15 Apr 2014, at 16:52, Dan Berindei <[email protected]> wrote:
> > > On Tue, Apr 15, 2014 at 5:29 PM, Radim Vansa <[email protected]> wrote: >> >> On 04/15/2014 02:31 PM, Galder Zamarreño wrote: >> >> On 09 Apr 2014, at 19:38, Dan Berindei <[email protected]> wrote: >> >> >> >> On Wed, Apr 9, 2014 at 5:37 PM, Galder Zamarreño <[email protected]> wrote: >> >> On 03 Apr 2014, at 11:38, Radim Vansa < >> [email protected] >> >> wrote: >> >> >> Hi, >> >> looking on the new configuration parser, I've noticed that you cannot >> configure ConsistentHashFactory anymore - is this by purpose? >> >> >> ^ Rather than being something the users should be tweaking, it’s something >> that’s used internally. So, I applied a bit of if-in-doubt-leave-it-out >> logic. I don’t think we lose any major functionality with this. >> >> >> For now it's the only way for the user to use the >> SyncConsistentHashFactory, so it's not used just internally. >> >> What’s the use case for that? The javadoc is not very clear on the benefits >> of using it. >> >> >> >> One use case I've noticed is having two caches with same keys, and >> modification listener handler retrieving data from the other cache. In >> order to execute the listener soon, you don't want to execute remote >> gets, and therefore, it's useful to have the hashes synchronized. >> > > Erik is using it with distributed tasks. Normally, keys with the same group > in multiple caches doesn't guarantee you that the keys are all located on the > same nodes, which means we can't guarantee that a distributed task that > accesses multiple caches has all the keys it needs locally just with > grouping. SyncConsistentHashFactory fixes that. Thanks Radim and Dan. Based on a further chat I had with Dan, I’ve sent a PR to update the SyncCHF javadoc to explain why that class exists in the first place: https://github.com/infinispan/infinispan/pull/2528 @Dan, have a look and see if you’re happy. Btw, I’ve just created https://issues.jboss.org/browse/ISPN-4245 to address this configuration issue. Cheers, > > >> >> Radim >> >> >> >> >> >> Another my concern is the fact that you enable stuff by parsing the >> element - for example L1. I expect that omitting the element and setting >> it with the default value (as presented in XSD) makes no difference, but >> this is not how current configuration works. >> >> >> L1 is disabled by default. You enable it by configuring the L1 lifespan to >> be bigger than 0. The attribute definition follows the pattern that Paul did >> for the server side. >> >> >> My opinion comes probably too late as the PR was already reviewed, >> discussed and integrated, but at least, please clearly describe the >> behaviour in the XSD. The fact that l1-lifespan "Defaults to 10 >> minutes." is not correct - it defaults to L1 being disabled. >> >> >> Yeah, I’ll update the XSD and documentation accordingly: >> >> >> https://issues.jboss.org/browse/ISPN-4195 >> >> >> >> Cheers >> >> >> >> Thanks >> >> Radim >> >> -- >> Radim Vansa <[email protected]> >> JBoss DataGrid QA >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> >> _______________________________________________ >> 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 >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> -- >> >> Radim Vansa <[email protected]> >> JBoss DataGrid QA >> >> _______________________________________________ >> 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 -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
