Hi,
as part of OAK-1980 I recently extended the IndexPlan with additional
methods like getDefinition(). This method returns the NodeState of the
index definition and allows you to identify the associated index in
content when the plan is executed. Maybe this is already sufficient for
your
Hi Vikas,
Sizing the cache can be done by either number of entries or the size
taken by cache. Currently in Oak we limit by size however as you
mentioned limit by count is more deterministic. We use Guava Cache and
it supports either limiting by size or by number of entries i.e. the
two policies
On Tue, Aug 19, 2014 at 11:59 AM, Marcel Reutegger mreut...@adobe.com wrote:
Maybe this is already sufficient for
your requirement?
Yup that would serve the purpose. For now I do not require that
support after following Thomas suggestion about using one index per
implementation. So for multiple
Hi,
I think it depends on the use case. e.g. how frequently do you
modify the list? how many 'producers' (sessions adding nodes) and
'consumers' (sessions removing nodes) do you have? is it OK if the
query result is slightly out of date? etc.
an async ordered index is probably a good choice if
Hello team,
as part of OAK-2035 I had to copy some helpers from oak-core to
oak-jcr. I was in a hurry so I copied
oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/util/ValuePathTuple.java
and some functions I pasted in OrderedIndexIT.java.
Now I was thinking what would be a proper way to
Hi,
Limiting the cache size by number of entries doesn't make sense. It is a
sure way to run into out of memory, exactly because the sizes of documents
varies a lot.
as you mentioned limit by count is more deterministic.
How, or in what way, is it more deterministic?
sysadmin can be provided
Hi Thomas,
On Tue, Aug 19, 2014 at 6:13 PM, Thomas Mueller muel...@adobe.com wrote:
How, or in what way, is it more deterministic?
Missed providing some context there so here are the details. Currently
we limit the cache by total size taken. Now given a system where you
have say 32 GB RAM
sysadmin can be provided with a rough idea about relation of (frequently
used) repo nodes using which sysadmin can update cache size.
I can't follow you, sorry. How would a sysadmin possibly know the number
of frequently used nodes? And why would he know that, and not the amount
of memory?
We use Guava Cache and
it supports either limiting by size or by number of entries i.e. the
two policies are exclusive.
Hmm I totally missed this point.
So at minimum if you can provide a patch which allows the admin to
choose between the two it would allow us to experiment and later see
