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