Hey Tristan,
----- Original Message -----
From: "Tristan Tarrant" <ttarrant(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: "Dan Berindei" <dberinde(a)redhat.com>
Sent: Tuesday, September 16, 2014 12:11:50 PM
Subject: Re: [infinispan-dev] Differences between default values in the XSD and the
code...Part One
On 16/09/14 12:04, Alan Field wrote:
> Hey,
>
> I have been looking at the differences between default values in the XSD vs
> the default values in the configuration builders. [1] I created a list of
> differences and talked to Dan about his suggestion for the defaults. The
> numbers in parentheses are Dan's suggestions, but he also asked me to post
> here to get a wider set of opinions on these values. This list is based on
> the code used in infinispan-core, so I still need to go through the server
> code to check the default values there.
>
> 1) For locking, the code has concurrency level set to 32, and the XSD has
> 1000 (32)
> 2) For eviction:
> a) the code has max entries set to -1, and the XSD has 10000 (-1)
> b) the code has interval set to 60000, and the XSD has 5000 (60000)
> 3) For async configuration:
> a) the code has queue size set to 1000, and the XSD has 0 (0)
> b) the code has queue flush interval set to 5000, and the XSD has 10
> (10)
> c) the code has remote timeout set to 15000, and the XSD has 17500
> (15000)
> 4) For hash, the code has number of segments set to 60, and the XSD has 80
> (60)
> 5) For l1, the code has l1 cleanup interval set to 600000, and the XSD has
> 60000 (60000)
>
> Please let me know if you have any opinions on these default values, and
> also if you have any ideas for avoiding these differences in the future.
> It seems like there are two possibilities at this point:
>
> 1) Generating the XSD from the source code
Impractical without a ton of annotations, since the builder structure is
very different from the XSD structure.
I think it would also require a lot of renaming variables in the code to match the names
in XSD.
> 2) Creating a test case that parses the XSD, creates a cache,
and verifies
> the default values against the parsed values
Server has a subsystem writer which recreates the configuration from the
in-memory model, maybe it's worth adapting that.
This sounds interesting. Can you point me to this code?
Thanks,
Alan
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev