Jackrabbit 1.3.1 Cache Management, some questions

[Clark Chang <cl...@thomson.com>]

Hi, We are using jackrabbit as the server mode accessing through RMI,
The standard way to acces it:

ClientRepositoryFactory factory = new ClientRepositoryFactory();
Repository repository = factory.getRepository(name);
Credentials credentials = new SimpleCredentials("user",
"pass".toCharArray());
Session session = repository.login(credentials);
try {
//do stuff
}finally{
 session.logout();
}

The questions is if I forget to call session.logout(), I notice the
CacheManager size get increased and after running this main routine several
times, eventually performance will degrade and will cause out of the memory
error.
This case is intentional, of course is the application developer's fault.
But in case there are RMI clients die without any chance to call the clean
up code, would have the same effect. Does jackrabbit have any defensive
mechnism, at least something like timeout to prevent this?

Thanks.

Clark
-- 
View this message in context: http://www.nabble.com/Jackrabbit-1.3.1-Cache-Management%2C-some-questions-tf4402953.html#a12560474
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: Jackrabbit 1.3.1 Cache Management, some questions

[Marcel Reutegger <ma...@gmx.net>]

Clark Chang wrote:
> Thanks for the reply. I did read the Jira issue about the timeout as you
> mentioned.
> Actually, We tested to leave the session open and garbage collect all the
> associated resources at the client side (hence should be the session
> itself), but it seems that the CacheManager still keep those extra caches
> related to that session.

the CacheManager only keeps weak references to the caches. there must be some 
other instance holding hard references to the cache.

regards
  marcel

Re: Jackrabbit 1.3.1 Cache Management, some questions

[Clark Chang <cl...@thomson.com>]

Jukka:

Thanks for the reply. I did read the Jira issue about the timeout as you
mentioned.
Actually, We tested to leave the session open and garbage collect all the
associated resources at the client side (hence should be the session
itself), but it seems that the CacheManager still keep those extra caches
related to that session.

Clark
-- 
View this message in context: http://www.nabble.com/Jackrabbit-1.3.1-Cache-Management%2C-some-questions-tf4402953.html#a12565318
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: Jackrabbit 1.3.1 Cache Management, some questions

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 9/7/07, Clark Chang <cl...@thomson.com> wrote:
> Hi, We are using jackrabbit as the server mode accessing through RMI,
> The standard way to acces it:
>
> ClientRepositoryFactory factory = new ClientRepositoryFactory();
> Repository repository = factory.getRepository(name);
> Credentials credentials = new SimpleCredentials("user",
> "pass".toCharArray());
> Session session = repository.login(credentials);
> try {
> //do stuff
> }finally{
>  session.logout();
> }

Perfect, looks nice!

> The questions is if I forget to call session.logout(), I notice the
> CacheManager size get increased and after running this main routine several
> times, eventually performance will degrade and will cause out of the memory
> error.
> This case is intentional, of course is the application developer's fault.
> But in case there are RMI clients die without any chance to call the clean
> up code, would have the same effect. Does jackrabbit have any defensive
> mechnism, at least something like timeout to prevent this?

The RMI layer itself doesn't protect against that, as the case is
pretty much equivalent to a local client forgetting to close a
session.

A session timeout was suggested some time ago, but it's not
implemented and I'm not too convinced that adding one would be a good
idea (though won't object if someone submits a patch :-). A better
approach would probably be to detect when a Session instance gets
garbage collected and make sure that any associated resources are
properly released. I don't know if such cleanup is currently happening
or even if there aren't any internal hard references to created
sessions or resources like the item state caches that would prevent
them from being garbage collected...

BR,

Jukka Zitting