You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Paul PODGORSEK <Th...@hotmail.com> on 2009/10/28 13:53:26 UTC
Using JackRabbit on a server with high traffic
Hello,
I wanted to know if some of you are using JackRabbit on a server
used by many users (about 35 single users per minute).
I am currently getting
problems on my application because it seems JackRabbit doesn't respond quickly
enough.
Is JackRabbit supposed to be working with
high traffic, or should it only be used as a kind of
datawarehouse?
Moreover, if it indeed can handle many connections at the
same time, what could explain the bottleneck that comes from JackRabbit? Having
had a look at the source code, I am wondering whether the synchronized methods
in the
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager
class aren't causing our problems. As far as I have looked, it seems only one
user can access the repository at a time (this seems very strange!). Am I right?
If yes, does someone know why it behaves that way?
I was also wondering if changing the locking policy could be a good
idea: our application on the server only reads content in JackRabbit (the
content is written into the repository via a separate batch, so there is no need
to synchronize read / write outside the batch). Do you think I could improve
performances by only giving a "fake" lock that doesn't lock anything when we try
to read content in the repository?
Last question: it is possible to specify a cache size in the org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager (see the attached jackrabbit-repository.xml file). Is
it a cache of objects fetched from the repository? or does it cache
something else instead? Why do we need to give a max amount of memory to use,
instead of giving a max number of objects in the cache? (like ehcache
does)
The application is running on a WebLogic server and all content is stored into an Oracle database.
I also added our repository configuration file to this email (we are using a 1.6 patched version of JackRabbit).
Any help will be greatly appreciated!
Thank you very much.
Kind
regards,
Paul.
_________________________________________________________________
Nouveau! Découvrez le Windows phone Samsung Omnia II disponible chez SFR.
http://clk.atdmt.com/FRM/go/175819072/direct/01/
Re: Using JackRabbit on a server with high traffic
Posted by Marcel Reutegger <ma...@gmx.net>.
On Wed, Oct 28, 2009 at 13:53, Paul PODGORSEK
<Th...@hotmail.com> wrote:
> Hello,
>
> I wanted to know if some of you are using JackRabbit on a server
> used by many users (about 35 single users per minute).
> I am currently getting
> problems on my application because it seems JackRabbit doesn't respond quickly
> enough.
> Is JackRabbit supposed to be working with
> high traffic, or should it only be used as a kind of
> datawarehouse?
I think Jackrabbit can be useful for both.
> Moreover, if it indeed can handle many connections at the
> same time, what could explain the bottleneck that comes from JackRabbit? Having
> had a look at the source code, I am wondering whether the synchronized methods
> in the
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager
> class aren't causing our problems. As far as I have looked, it seems only one
> user can access the repository at a time (this seems very strange!). Am I right?
> If yes, does someone know why it behaves that way?
that is only access to the persistence layer. multiple JCR sessions
can work with the repository concurrently without problems. however
there may be access patterns that lead to a bottleneck in the
persistence manager. See also:
https://issues.apache.org/jira/browse/JCR-2345
> I was also wondering if changing the locking policy could be a good
> idea: our application on the server only reads content in JackRabbit (the
> content is written into the repository via a separate batch, so there is no need
> to synchronize read / write outside the batch). Do you think I could improve
> performances by only giving a "fake" lock that doesn't lock anything when we try
> to read content in the repository?
you could further scale the repository by using the clustering
feature. See: http://wiki.apache.org/jackrabbit/Clustering
> Last question: it is possible to specify a cache size in the org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager (see the attached jackrabbit-repository.xml file). Is
> it a cache of objects fetched from the repository? or does it cache
> something else instead?
you can configure the size of the bundle cache. a bundle consists of a
node and all its properties.
<param name="bundleCacheSize" value="128"/>
the value is in MB and defaults to 32.
> Why do we need to give a max amount of memory to use,
> instead of giving a max number of objects in the cache? (like ehcache
> does)
because it allows better control over how much memory is used. The
size of a bundle can be very variable, depending on how many
properties it has and what is stored in those properties.
regards
marcel
> The application is running on a WebLogic server and all content is stored into an Oracle database.
>
> I also added our repository configuration file to this email (we are using a 1.6 patched version of JackRabbit).
>
>
> Any help will be greatly appreciated!
> Thank you very much.
>
> Kind
> regards,
> Paul.
> _________________________________________________________________
> Nouveau! Découvrez le Windows phone Samsung Omnia II disponible chez SFR.
> http://clk.atdmt.com/FRM/go/175819072/direct/01/
RE: Using JackRabbit on a server with high traffic
Posted by Paul PODGORSEK <th...@hotmail.com>.
It seems the repository.xml file hasn't been sent with my last email.
Here it is.
Paul.
> From: The_Wizard_of_wind_Oz@hotmail.com
> To: users@jackrabbit.apache.org
> Subject: Using JackRabbit on a server with high traffic
> Date: Wed, 28 Oct 2009 13:53:26 +0100
>
> Hello,
>
> I wanted to know if some of you are using JackRabbit on a server
> used by many users (about 35 single users per minute).
> I am currently getting
> problems on my application because it seems JackRabbit doesn't respond quickly
> enough.
> Is JackRabbit supposed to be working with
> high traffic, or should it only be used as a kind of
> datawarehouse?
>
> Moreover, if it indeed can handle many connections at the
> same time, what could explain the bottleneck that comes from JackRabbit? Having
> had a look at the source code, I am wondering whether the synchronized methods
> in the
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager
> class aren't causing our problems. As far as I have looked, it seems only one
> user can access the repository at a time (this seems very strange!). Am I right?
> If yes, does someone know why it behaves that way?
>
> I was also wondering if changing the locking policy could be a good
> idea: our application on the server only reads content in JackRabbit (the
> content is written into the repository via a separate batch, so there is no need
> to synchronize read / write outside the batch). Do you think I could improve
> performances by only giving a "fake" lock that doesn't lock anything when we try
> to read content in the repository?
>
> Last question: it is possible to specify a cache size in the org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager (see the attached jackrabbit-repository.xml file). Is
> it a cache of objects fetched from the repository? or does it cache
> something else instead? Why do we need to give a max amount of memory to use,
> instead of giving a max number of objects in the cache? (like ehcache
> does)
>
> The application is running on a WebLogic server and all content is stored into an Oracle database.
>
> I also added our repository configuration file to this email (we are using a 1.6 patched version of JackRabbit).
>
>
> Any help will be greatly appreciated!
> Thank you very much.
>
> Kind
> regards,
> Paul.
_________________________________________________________________
Nouveau Windows 7 : Trouvez le PC qui vous convient. En savoir plus.
http://clk.atdmt.com/FRM/go/181574580/direct/01/