On 18.8.14 8:41 , KÖLL Claus wrote:
The longer we wait now the harder it will be to create clean and easier to
understand documentation
I agree we should do the move, however doubt that right now is a good
point in time. This will affect the ongoing work in theses areas, which
is all merge
On Mon, Aug 18, 2014 at 1:02 PM, Michael Dürig wrote:
> This will affect the ongoing work in theses areas, which is all merged back
> into the 1.0 branch. We should also consider Marcel and Alex, who will
> probably be most affected by the additional merge effort.
I also think that this refactori
Hi,
We were struggling past couple of weeks with severe performance issues
on AEM6/Oak/MongoNS -- fortunately the issue was due to VM we were
using. So, all seems well for now.
BUT, during investigation, one of the things that we were worried
about was document cache missing hits... we tried modi
Hello Vikas,
On 18/08/2014 12:05, Vikas Saurabh wrote:
> Hi,
>
> ...
> specify a cache size. While I agree that cache should be a memory
> hog... but entry size of a document in cache is quite variable in
> nature and as an admin I can make guesses about JCR nodes and their
> access patters. Docum
>> we can probably have both and cache respects whichever constraint hits
>> first (sort of min(byte size, entry size)).
> First of all I don't know MongoNS implementation details so I can be wrong.
>
> I'd rather keep the size in bytes as it gives me much more control over
> the memory I have and
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 requirem
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 a
On Tue, Aug 19, 2014 at 11:59 AM, Marcel Reutegger 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 Lucene index def
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 yo
