jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: JCR-RMI RangeIterator performance
Date Fri, 15 Apr 2005 19:08:55 GMT
Hi jukka

  thanks for making this kind of conversation public.

btw, Is there any progress in the components of your contrib proposal. 
I'm particularly interested in the audit trail layer.


Jukka Zitting wrote:
> Hi,
> [Moving a private discussion to the -dev list.]
> Tobias Strasser:
>  > one question: the RemoteNode.getNodes() returns an array of
>  > RemoteNodes. I not sure, who this performs for a large number of child
>  > nodes. The RangeIterator was introduced especially to circumvent such
>  > issues. maybe the RemoteNode should make use of the RangeIterator
>  > aswell?
> Felix Meschberger:
>> Re RangeIterators: Maybe this is the easiest and most straight forward 
>> way to transfer the RangeIterator stuff over the net... I think, it 
>> should probably be possible to have some sort of a RemoteRangeIterator 
>> ? Jukka is there a reason for not having one ? I agree with Tobias' 
>> concern on performance, actually I seem to hit at them :-)
> My design goal for JCR-RMI was to keep it as simple and straightforward 
> as possible while trying to minimize network traffic, especially the 
> amount of round-trips to the server. In many cases reducing server 
> round-trips requires separate caching, with associated validity 
> problems, but RangeIterators and Values can normally be cached without 
> problems (AFAIK).
> I think the iterators-as-arrays design decision causes problems only 
> when there are thousands of iterated items, causing noticeable network 
> bandwidth, serialization/deserialization, and object instantiation 
> delays. I believe that a normal JCR client always iterates through all 
> or most of the received iterator elements, thus negating the problem of 
> transmmitting too much data.
> If this is a problem, it would be easy to create separate 
> RemoteRangeIterator interfaces as suggested by Felix. There could be an 
> optional  ClientRepository attribute that can be used for selecting the 
> desired iterator behaviour on the client side. Even better, the server 
> could dynamically decide whether to return an array or an iterator based 
> on the size of the underlying data set.
> Anyhow, I have not yet really been focusing on performance of JCR-RMI. 
> My initial plan was to introduce a separate general caching layer on top 
> of JCR-RMI as an optional performance booster, but so far I haven't had 
> time to do anything substantial with that idea.
> BR,
> Jukka Zitting

View raw message