Model 3 deployment status

["Thomas M. Duffey" <td...@utilivisor.com>]

Hi All,

The "Repository Server HOWTO" warns that the current implementation  
has serious performance issues.  Does anyone know just how serious  
these issues and if anyone is working on improvements?  If this model  
is not ready for prime time then how are people using Jackrabbit in  
clustered application server environments?  I understand these are  
difficult questions to answer but any insight or advice on using  
Jackrabbit as a repository server will help!

Best Regards,

Tom Duffey

Re: Model 3 deployment status

[Alexandru Popescu <th...@gmail.com>]

#: Jukka Zitting changed the world a bit at a time by saying on  9/30/2005 12:23 AM :#
> Hi,
> 
> Alexandru Popescu wrote:
>>> Another more advanced optimization would be to host the
>>> entire transient session state at the client side and only
>>> sending changes over the network when the save() method is invoked.
>>
>> Shouldn't this be required to happen? (session `flushing´ only on 
>> save). In all other cases I think that the remote repository should 
>> have a session management mechanism that is reusing the same session 
>> for a client that haven't submitted yet the save() ).
> 
> The API obviously suggests an implementation like that. This is however no
> strict requirement, and the transient state can therefore be managed on either
> side of the network link. The fact that JCR-RMI is a layer *on top of* the JCR
> API makes it much easier to keep the transient state on the server side 
> than on
> the client side, thus causing the performance issues. A network layer 
> that works
> *below* the JCR API could easily be made much more efficient, but the downside
> is that such a layer would be tightly bound to a single repository
> implementation.
> 
> In fact it would be quite interesting to investigate the feasibility of such a
> network layer for Jackrabbit. Do any of the other content repository
> implementations implement anything like that? Is there general interest in a
> such a feature? If there is enough interest we might want to consider
> implementing something like that somewhere around Jackrabbit 1.2 or 2.0. :-)
> 

If you are referring to a rmi communication layer I've got answers from exo-jcr that they are 
supporting the same scenario. But because exo-jcr RC1 was announced in may and nothing new was 
released I haven't spent time investigating this (they don't support yet optional features, so it 
was not so interesting to me).

The same question went to the CRX, and I guess the answer is obvious. I don't know anything about 
jeceira but it is very very young so I don't think the guys there have spent a lot of time on this.


>>> [...]
>>> the biggest performance issues by the time the Jackrabbit 1.0 
>>> release is made.
>>
>> Are we talking about something scheduled here :-) ?
> 
> :-) Well, you know the open source schedules, it's ready when it's ready...
> Anyhow, I'd be surprised if JCR-RMI performance would not be much improved by
> the end of this year. All sorts of help (bug reports, comments, docs, patches,
> testing, etc.) is of course very much welcome.
> 
> As for the Jackrabbit 1.0 schedule, I'll get back to that soon enough in a
> separate message.
> 

I am getting the feeling you are preparing us a surprise ;-).

./alex
--
.p( the_mindstorm )q.

> BR,
> 
> Jukka Zitting
> 

Re: Model 3 deployment status

[Jukka Zitting <ju...@zitting.name>]

Hi,

Alexandru Popescu wrote:
>> Another more advanced optimization would be to host the
>> entire transient session state at the client side and only
>> sending changes over the network when the save() method is invoked.
>
> Shouldn't this be required to happen? (session `flushing´ only on 
> save). In all other cases I think that the remote repository should 
> have a session management mechanism that is reusing the same session 
> for a client that haven't submitted yet the save() ).

The API obviously suggests an implementation like that. This is however no
strict requirement, and the transient state can therefore be managed on either
side of the network link. The fact that JCR-RMI is a layer *on top of* the JCR
API makes it much easier to keep the transient state on the server side 
than on
the client side, thus causing the performance issues. A network layer 
that works
*below* the JCR API could easily be made much more efficient, but the downside
is that such a layer would be tightly bound to a single repository
implementation.

In fact it would be quite interesting to investigate the feasibility of such a
network layer for Jackrabbit. Do any of the other content repository
implementations implement anything like that? Is there general interest in a
such a feature? If there is enough interest we might want to consider
implementing something like that somewhere around Jackrabbit 1.2 or 2.0. :-)

>> [...]
>> the biggest performance issues by the time the Jackrabbit 1.0 
>> release is made.
>
> Are we talking about something scheduled here :-) ?

:-) Well, you know the open source schedules, it's ready when it's ready...
Anyhow, I'd be surprised if JCR-RMI performance would not be much improved by
the end of this year. All sorts of help (bug reports, comments, docs, patches,
testing, etc.) is of course very much welcome.

As for the Jackrabbit 1.0 schedule, I'll get back to that soon enough in a
separate message.

BR,

Jukka Zitting

Re: Model 3 deployment status

[Alexandru Popescu <th...@gmail.com>]

#: Jukka Zitting changed the world a bit at a time by saying on  9/29/2005 10:32 PM :#
> Hi,
> 
> Thomas Duffey wrote:
>> The "Repository Server HOWTO" warns that the current implementation  
>> has serious performance issues.  Does anyone know just how serious  
>> these issues and if anyone is working on improvements?  If this model 
>>  is not ready for prime time then how are people using Jackrabbit in  
>> clustered application server environments?  I understand these are  
>> difficult questions to answer but any insight or advice on using  
>> Jackrabbit as a repository server will help!
> 
> The JCR-RMI layer that the warning on the HOWTO page refers to is currently
> designed for simplicity instead of performance. The current 
> implementation maps
> almost all API calls to remote method invocations, which results in 
> many network
> roundtrips for even relatively simple repository operations. Simple
> optimizations like streaming all query results in a single operation 
> would go a
> long way to improving the performance. Another more advanced 
> optimization would
> be to host the entire transient session state at the client side and only
> sending changes over the network when the save() method is invoked.
> 

Shouldn't this be required to happen? (session `flushing´ only on save). In all other cases I think 
that the remote repository should have a session management mechanism that is reusing the same 
session for a client that haven't submitted yet the save() ).



> [...]
> the biggest performance issues by the time the Jackrabbit 1.0 release is made.
> 

Are we talking about something scheduled here :-) ?

cheers,

./alex
--
.the_mindstorm.

> BR,
> 
> Jukka Zitting
> 

Re: Model 3 deployment status

[Jukka Zitting <ju...@zitting.name>]

Hi,

Thomas Duffey wrote:
> The "Repository Server HOWTO" warns that the current implementation  
> has serious performance issues.  Does anyone know just how serious  
> these issues and if anyone is working on improvements?  If this model 
>  is not ready for prime time then how are people using Jackrabbit in  
> clustered application server environments?  I understand these are  
> difficult questions to answer but any insight or advice on using  
> Jackrabbit as a repository server will help!

The JCR-RMI layer that the warning on the HOWTO page refers to is currently
designed for simplicity instead of performance. The current 
implementation maps
almost all API calls to remote method invocations, which results in 
many network
roundtrips for even relatively simple repository operations. Simple
optimizations like streaming all query results in a single operation 
would go a
long way to improving the performance. Another more advanced 
optimization would
be to host the entire transient session state at the client side and only
sending changes over the network when the save() method is invoked.

I've recently started focusing more on the performance and resource issues of
JCR-RMI, but I haven't really made much visible progress yet as I've been
somewhat occupied by other work. So far I've done some initial benchmarks and
have a pretty good picture of the worst bottlenecks. I'm hoping to have solved
the biggest performance issues by the time the Jackrabbit 1.0 release is made.

BR,

Jukka Zitting