On 28 Apr 2014, at 16:42, Galder Zamarreño <[email protected]> wrote:

> 
> 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.

@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 <[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


--
Galder Zamarreño
[email protected]
twitter.com/galderz


_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to