[infinispan-dev] New configuration

Galder Zamarreño galder at redhat.com
Wed Jul 16 09:25:01 EDT 2014


On 28 Apr 2014, at 16:42, Galder Zamarreño <galder at redhat.com> wrote:

> 
> On 15 Apr 2014, at 16:52, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
>> 
>> 
>> On Tue, Apr 15, 2014 at 5:29 PM, Radim Vansa <rvansa at redhat.com> wrote:
>>> 
>>> On 04/15/2014 02:31 PM, Galder Zamarreño wrote:
>>> 
>>> On 09 Apr 2014, at 19:38, Dan Berindei <dan.berindei at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Wed, Apr 9, 2014 at 5:37 PM, Galder Zamarreño <galder at redhat.com> wrote:
>>> 
>>> On 03 Apr 2014, at 11:38, Radim Vansa <
>>> rvansa at redhat.com
>>> 
>>> 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.

@Radim FYI, PR for ^ https://github.com/infinispan/infinispan/pull/2725

> 
> 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 <rvansa at redhat.com>
>>>   JBoss DataGrid QA
>>> 
>>>   _______________________________________________
>>>   infinispan-dev mailing list
>>>   infinispan-dev at lists.jboss.org
>>> 
>>> 
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> 
>>> 
>>> --
>>> Galder Zamarreño
>>> galder at redhat.com
>>> twitter.com/galderz
>>> 
>>> 
>>> _______________________________________________
>>> 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
>>> 
>>> --
>>> Galder Zamarreño
>>> galder at redhat.com
>>> twitter.com/galderz
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> 
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss DataGrid QA
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz




More information about the infinispan-dev mailing list