Julian Reschke wrote:
OK,
I finally obtained measurements for jackrabbit native and JCR2SPI (see
proposed test in JCR-1437):
jackrabbit-core: 3.35ms per iteration
jcr2spi: 756ms per iteration
Hopefully once the tests are checked-in, and the results are
reproducible everywhere, we agree
OK,
I finally obtained measurements for jackrabbit native and JCR2SPI (see
proposed test in JCR-1437):
jackrabbit-core: 3.35ms per iteration
jcr2spi: 756ms per iteration
Hopefully once the tests are checked-in, and the results are
reproducible everywhere, we agree that there's a problem :-)
hi marcel
Marcel Reutegger wrote:
Here's another idea:
introduce a method ChildInfo[] NodeInfo.getChildInfos(). The method
either returns:
- all child infos, which also gives the correct number of child nodes.
this may also mean that an empty array is returned to indicate there are
no
Julian Reschke wrote:
Why don't we change things so that ItemInfo *extends* ChildInfo,
that doesn't make sense from my point of view.
the usecase for the ChildInfo was to be able to build
the HierarchyEntry for a Node where neither ids of
the child-entries nor the references are required.
Julian Reschke wrote:
- change the return value of getChildInfos so that size information is
there (Iterator - RangeIterator or Collection)
didn't we have that discussion before? (JCR-1239)
since jcr2spi will still have to process the Iterator in order
to populate the hierarchy in order to
Angela Schreiber wrote:
Julian Reschke wrote:
- change the return value of getChildInfos so that size information is
there (Iterator - RangeIterator or Collection)
didn't we have that discussion before? (JCR-1239)
We didn't come to a conclusion (it's an open issue). I'm looking for a
Angela Schreiber wrote:
Julian Reschke wrote:
Why don't we change things so that ItemInfo *extends* ChildInfo,
that doesn't make sense from my point of view.
the usecase for the ChildInfo was to be able to build
the HierarchyEntry for a Node where neither ids of
the child-entries nor the
Julian Reschke wrote:
Why don't we change things so that ItemInfo *extends* ChildInfo, so that
SPI implementations can return NodeInfos as well? JCR2SPI could then use
that to update its internal cache, avoiding to refetch the NodeInfos.
I'd rather keep it the way it is right now, but
I'm not particularly attached to a specific solution, as long as we make
progress.
That being said, here are a few comments on the proposal below:
- what we don't have is an efficient way to query a set of properties,
with the ability for the SPI to return more; similarly to what we do
with
Hi,
I've been playing around with SPI-side caching of the result of
getChildInfos() (keeping the associated NodeInfos in memory), and I can
gain something like a factor of 8 for SPI access.
So getting back to Marcel's ideas:
Why don't we change things so that ItemInfo *extends* ChildInfo,
Julian Reschke wrote:
At the end of the day, what we should do is *measure* the performance of
JCR2SPI compared to native implementations. I'll try to submit a few
tests soon.
...
OK, I've got tests (not polished) and numbers.
Scenario:
A collection /a/b with 500 members, each 1024 in
Marcel Reutegger wrote:
Hmmm, does that mean a batch read should also be allowed to return
ChildInfo, with the restriction that it must be complete, when sent?
That would be less expensive than returning ItemInfos for the
children. But would it be useful?
Maybe the more interesting question
David Rauschenbach wrote:
Back to the discussion: also worth mentioning is why a requested-depth
argument is missing from getItemInfos.
first: spi is not webdav.
second: at the last spi f2f (public invitation,
attendees: julian, marcel, jukka, myself)
we discussed the batch-read.
we decided:
David Rauschenbach wrote:
also worth mentioning is why a requested-depth argument is missing from
getItemInfos. It's just a little strange for the server to choose what to do,
or to have a pre-configured nodetype-specific batch strategy configured
there, when the client is where it's at, where
David Rauschenbach wrote:
Distraction:
WebDAV notation is better for examples (nodes/collections end with slashes,
items don't):
a/
b/
c/
p1
p2
d/
Back to the discussion: also worth mentioning is why a requested-depth argument
is missing from getItemInfos. It's just a little
Julian Reschke wrote:
Marcel Reutegger wrote:
David Rauschenbach wrote:
My main problem with SPI is that if I return depth=1 results from
getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up
subsequently
calling getChildInfos anyway, to find out what ALL the children are,
regardless
David Rauschenbach wrote:
My main problem with SPI is that if I return depth=1 results from
getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up subsequently
calling getChildInfos anyway, to find out what ALL the children are,
regardless of the fact that I just returned what all the
Marcel Reutegger wrote:
David Rauschenbach wrote:
My main problem with SPI is that if I return depth=1 results from
getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up
subsequently
calling getChildInfos anyway, to find out what ALL the children are,
regardless of the fact that I
Marcel Reutegger wrote:
How would JCR2SPI that *all* children have been returned?
good question! I don't know. I'm not that familiar anymore with the
jcr2spi code. I remember a discussion with angela about a flag, which
indicates that child node entries are complete. But I guess we never
Julian Reschke wrote:
Marcel Reutegger wrote:
I think your question reveals a design flaw in the batch read method
RepositoryService.getItemInfos(). And it's not just about knowing all
children, it's also about the order of nodes. Even if we are sure we
got all children we still have to call
Marcel Reutegger wrote:
Julian Reschke wrote:
The store the SPI implementation talks to internally may be on a
separate machine, so verifying that something is up-to-date (for read
access) would actually defy the caching in the first place, wouldn't it?
IMO an SPI implementation was never
Julian Reschke wrote:
If the JCR client does call refresh(), we really should pass that
information to SPI, either by a new method (which could be more
elaborate than just refresh() as mentioned by Angela), or just discard
the SessionInfo and get a fresh one.
i wouldn't state, that we pass
Marcel Reutegger wrote:
Example - obtaining a directory listing: SPI2JCR currently gets the
NodeInfo for the collection, then gets the ChildInfo iterator, then
for each NodeId of a child fetches that child's NodeInfo.
For a collection of N members, this translates to N additional
roundtrips
Julian Reschke wrote:
I think I understand batch read, and how JCR2SPI would use that. What I
don't see how it helps in this case.
An SPI implementation *could* return ItemInfos for all children when the
NodeInfo for a collection is fetched, but how would it know that anybody
wants to see
My main problem with SPI is that if I return depth=1 results from getItemInfos
(a NodeInfo for each subfolder), JCR2SPI ends up subsequently calling
getChildInfos anyway, to find out what ALL the children are, regardless of the
fact that I just returned what all the children are in my
Hi,
this issue made me think that we may be missing something in the SPI...
So, is an SPI implementation allowed to internally cache things (for
instance, with the SessionInfo implementation)? I would assume so (but
maybe I'm wrong).
If it is allowed to do that, shouldn't a
hi julian
this issue made me think that we may be missing something in the SPI...
So, is an SPI implementation allowed to internally cache things (for
instance, with the SessionInfo implementation)? I would assume so (but
maybe I'm wrong).
If it is allowed to do that, shouldn't a
27 matches
Mail list logo
