You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Shaun Barriball <sb...@yahoo.co.uk> on 2007/03/27 12:06:13 UTC
Profiling shows Session management to be a hotspot - session pooling etc
Hi all,
We're currently CPU profiling an application which uses the SessionInView
pattern to create a new JCR session (with JackRabbit) for each request.
Profiling shows that around:
- 11.4% of the CPU time is in releaseSession(). In particular around 5% of
this is in ItemManager.evictItem().
- 0.08% of the CPU time is in getSession()
For each request the application is just reading a set of nodes (upto around
100) to generate a web page. We're using JackRabbit 1.2.1 with Oracle.
Any recommendations for how to resolve this overhead?
- should we consider pooling sessions?
- any way to optimise the session usage given the nodes are all read-only?
All help appreciated.
Regards,
Shaun.
___________________________________________________________
All New Yahoo! Mail � Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
Re: Profiling shows Session management to be a hotspot - session
pooling etc
Posted by Brian Thompson <el...@gmail.com>.
Hmm...if your code base can support it easily, I'd say share a session
between Reader threads (with try-catch for the InvalidItemStateException
added) and instantiate separate sessions for each Editor request.
So yes, I think you're most likely getting that exception because of the
non-ACID way you're using sessions.
-Brian
Shaun Barriball wrote:
> Thanks for the response Brian.
> We're using Spring to setup the Sessions for both the Editor and Reader but
> we're not currently associating it with a transaction.
> So by your comment "ensure everything that modifies the repository happens
> transactionally" is it best to:
>
> * ensure the "Editor" app associates every update operation in a
> transaction to ensure atomicity etc (ACID)
>
> * ensure the "Reader" app associates the session with a transaction for the
> duration of a request which should guarantee a consistent view on JCR and
> avoid the InvalidItemStateException otherwise known as the "carpet being
> pulled from under you".
>
> So I'm presuming the exception is due to the non-ACID way in which we're
> using the repos?
>
> Regards,
> Shaun.
RE: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Thanks for the response Brian.
We're using Spring to setup the Sessions for both the Editor and Reader but
we're not currently associating it with a transaction.
So by your comment "ensure everything that modifies the repository happens
transactionally" is it best to:
* ensure the "Editor" app associates every update operation in a
transaction to ensure atomicity etc (ACID)
* ensure the "Reader" app associates the session with a transaction for the
duration of a request which should guarantee a consistent view on JCR and
avoid the InvalidItemStateException otherwise known as the "carpet being
pulled from under you".
So I'm presuming the exception is due to the non-ACID way in which we're
using the repos?
Regards,
Shaun.
-----Original Message-----
From: Brian Thompson [mailto:elephantium@gmail.com]
Sent: 29 March 2007 17:29
To: users@jackrabbit.apache.org
Subject: Re: Profiling shows Session management to be a hotspot - session
pooling etc
You might wrap methods that use the shared session in a try-catch block. If
that exception gets thrown, acquire a new session and retry the action.
You'll need to ensure that everything that modifies the repository happens
transactionally, but this might be a solution.
-Brian
On 3/29/07, Shaun Barriball <sb...@yahoo.co.uk> wrote:
>
> Hi all,
> Yesterday we modified our 'view' web application to use a shared
> global Session rather than Session per request pattern based on
> (appreciated) feedback from the list. The result was a large increase
> in performance but we are now seeing the following exception thrown
periodically:
>
> Caused by: javax.jcr.InvalidItemStateException:
> 5f3e21de-2ba9-43bf-b096-1d80cc406efa/{
> http://www.acme.co.uk/xmlns/contentmod
> el}styleClass: the item does not exist anym ore
> at
> org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
> at
> org.apache.jackrabbit.core.PropertyImpl.getName(PropertyImpl.java:1154
> )
>
> .....which implies that the session is getting out of date with
> changes made by the 'editor' web application. We're using a mdoel 2
> deployment.
>
> Is there anything we could be doing wrong in our code for this to
> occur or is using a shared session a not viable?
>
> Regards,
> Shaun.
>
>
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: 27 March 2007 14:45
> To: users@jackrabbit.apache.org
> Subject: Re: Profiling shows Session management to be a hotspot -
> session pooling etc
>
> Hi,
>
> On 3/27/07, David Nuescheler <da...@gmail.com> wrote:
> > the only issue that i am aware of with respect to concurrent read
> > operations on a shared session is during shutdown under certain
> > special
> conditions.
> > generally an application should be able to concurrently read from
> > the same session
>
> Note that while this is currently true in Jackrabbit, it might not be
> true in some other JCR implementation or in a future Jackrabbit
> release. We might for example want to introduce some session-level
> read cache that would not be thread-safe.
>
> I would recommend using a thread pool instead of accessing a single
> session from multiple threads.
>
> BR,
>
> Jukka Zitting
>
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
Re: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Brian Thompson <el...@gmail.com>.
You might wrap methods that use the shared session in a try-catch block. If
that exception gets thrown, acquire a new session and retry the action.
You'll need to ensure that everything that modifies the repository happens
transactionally, but this might be a solution.
-Brian
On 3/29/07, Shaun Barriball <sb...@yahoo.co.uk> wrote:
>
> Hi all,
> Yesterday we modified our 'view' web application to use a shared global
> Session rather than Session per request pattern based on (appreciated)
> feedback from the list. The result was a large increase in performance but
> we are now seeing the following exception thrown periodically:
>
> Caused by: javax.jcr.InvalidItemStateException:
> 5f3e21de-2ba9-43bf-b096-1d80cc406efa/{
> http://www.acme.co.uk/xmlns/contentmod
> el}styleClass: the item does not exist anym
> ore
> at
> org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
> at
> org.apache.jackrabbit.core.PropertyImpl.getName(PropertyImpl.java:1154)
>
> .....which implies that the session is getting out of date with changes
> made
> by the 'editor' web application. We're using a mdoel 2 deployment.
>
> Is there anything we could be doing wrong in our code for this to occur or
> is using a shared session a not viable?
>
> Regards,
> Shaun.
>
>
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: 27 March 2007 14:45
> To: users@jackrabbit.apache.org
> Subject: Re: Profiling shows Session management to be a hotspot - session
> pooling etc
>
> Hi,
>
> On 3/27/07, David Nuescheler <da...@gmail.com> wrote:
> > the only issue that i am aware of with respect to concurrent read
> > operations on a shared session is during shutdown under certain special
> conditions.
> > generally an application should be able to concurrently read from the
> > same session
>
> Note that while this is currently true in Jackrabbit, it might not be true
> in some other JCR implementation or in a future Jackrabbit release. We
> might
> for example want to introduce some session-level read cache that would not
> be thread-safe.
>
> I would recommend using a thread pool instead of accessing a single
> session
> from multiple threads.
>
> BR,
>
> Jukka Zitting
>
RE: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Hi all,
Yesterday we modified our 'view' web application to use a shared global
Session rather than Session per request pattern based on (appreciated)
feedback from the list. The result was a large increase in performance but
we are now seeing the following exception thrown periodically:
Caused by: javax.jcr.InvalidItemStateException:
5f3e21de-2ba9-43bf-b096-1d80cc406efa/{http://www.acme.co.uk/xmlns/contentmod
el}styleClass: the item does not exist anym
ore
at
org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
at
org.apache.jackrabbit.core.PropertyImpl.getName(PropertyImpl.java:1154)
.....which implies that the session is getting out of date with changes made
by the 'editor' web application. We're using a mdoel 2 deployment.
Is there anything we could be doing wrong in our code for this to occur or
is using a shared session a not viable?
Regards,
Shaun.
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: 27 March 2007 14:45
To: users@jackrabbit.apache.org
Subject: Re: Profiling shows Session management to be a hotspot - session
pooling etc
Hi,
On 3/27/07, David Nuescheler <da...@gmail.com> wrote:
> the only issue that i am aware of with respect to concurrent read
> operations on a shared session is during shutdown under certain special
conditions.
> generally an application should be able to concurrently read from the
> same session
Note that while this is currently true in Jackrabbit, it might not be true
in some other JCR implementation or in a future Jackrabbit release. We might
for example want to introduce some session-level read cache that would not
be thread-safe.
I would recommend using a thread pool instead of accessing a single session
from multiple threads.
BR,
Jukka Zitting
___________________________________________________________
All New Yahoo! Mail � Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
Re: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/27/07, David Nuescheler <da...@gmail.com> wrote:
> the only issue that i am aware of with respect to concurrent read operations on
> a shared session is during shutdown under certain special conditions.
> generally an application should be able to concurrently read from the
> same session
Note that while this is currently true in Jackrabbit, it might not be
true in some other JCR implementation or in a future Jackrabbit
release. We might for example want to introduce some session-level
read cache that would not be thread-safe.
I would recommend using a thread pool instead of accessing a single
session from multiple threads.
BR,
Jukka Zitting
RE: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Hi David,
That all sounds like good news.
So to be clear....if I have an application architecture which consists of:
* "editor" webapp - performs read/write operations
* "viewer" webapp - performs only read operations
...then I can use a single shared session for all requests to "viewer" and it
will automatically pick-up committed changes made in the "editor" app?
The reason for the clarification is that we tried that scenario with an
older version of JackRabbit late last year and encountered various
InvalidItem/ItemNotExists type exceptions which we put down to accessing
'stale' cached content in the "viewer" app.
As an aside, it would be interesting to here (anyones) comments on the
impact of an architecture where "editor" and "viewer" are using separate but
clustered JackRabbit instances?
Regards,
Shaun.
-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]
Sent: 27 March 2007 14:26
To: users@jackrabbit.apache.org
Subject: Re: Profiling shows Session management to be a hotspot - session
pooling etc
hi shaun,
the only issue that i am aware of with respect to concurrent read operations
on a shared session is during shutdown under certain special conditions.
generally an application should be able to concurrently read from the same
session in jackrabbit and also updates to the content will be reflected in
the session without calling refresh().
regards,
david
___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html
Re: Profiling shows Session management to be a hotspot - session pooling etc
Posted by David Nuescheler <da...@gmail.com>.
hi shaun,
the only issue that i am aware of with respect to concurrent read operations on
a shared session is during shutdown under certain special conditions.
generally an application should be able to concurrently read from the
same session
in jackrabbit and also updates to the content will be reflected in the session
without calling refresh().
regards,
david
RE: Profiling shows Session management to be a hotspot - session pooling etc
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Avim wrote "If you have no write operations, you can use a single session
for the hole application(!?)"
2 issues I'm aware of if we used a single session, say cached at the
ServletContext level:
1) I've read various threads which imply that a Session should only be
accessed via a single thread, and therefore a session cannot be shared
across parallel requests.
2) the data does change frequently therefore creating a new session ensures
its up to date. I guess if point 1) isn't an issue we could consider using a
SingleSession and periodically called refresh() on it.
If anyone can put my right on the above I'd appreciate it.
Regards,
Shaun.
-----Original Message-----
From: avim [mailto:avi.moradi@timetoknow.org]
Sent: 27 March 2007 12:15
To: users@jackrabbit.apache.org
Subject: Re: Profiling shows Session management to be a hotspot - session
pooling etc
Shaun Barriball wrote:
>
> Hi all,
> We're currently CPU profiling an application which uses the
> SessionInView pattern to create a new JCR session (with JackRabbit) for
each request.
>
> Profiling shows that around:
> - 11.4% of the CPU time is in releaseSession(). In particular around
> 5% of this is in ItemManager.evictItem().
> - 0.08% of the CPU time is in getSession()
>
> For each request the application is just reading a set of nodes (upto
> around
> 100) to generate a web page. We're using JackRabbit 1.2.1 with Oracle.
>
> Any recommendations for how to resolve this overhead?
> - should we consider pooling sessions?
> - any way to optimise the session usage given the nodes are all
> read-only?
> If you have no write operations, you can use a single session for the
> hole
> application(!?)
> All help appreciated.
> Regards,
> Shaun.
>
>
>
> ___________________________________________________________
> All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard
> protect you. http://uk.docs.yahoo.com/nowyoucan.html
>
>
--
View this message in context:
http://www.nabble.com/Profiling-shows-Session-management-to-be-a-hotspot---s
ession-pooling-etc-tf3472134.html#a9690383
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: Profiling shows Session management to be a hotspot - session
pooling etc
Posted by avim <av...@timetoknow.org>.
Shaun Barriball wrote:
>
> Hi all,
> We're currently CPU profiling an application which uses the SessionInView
> pattern to create a new JCR session (with JackRabbit) for each request.
>
> Profiling shows that around:
> - 11.4% of the CPU time is in releaseSession(). In particular around 5%
> of
> this is in ItemManager.evictItem().
> - 0.08% of the CPU time is in getSession()
>
> For each request the application is just reading a set of nodes (upto
> around
> 100) to generate a web page. We're using JackRabbit 1.2.1 with Oracle.
>
> Any recommendations for how to resolve this overhead?
> - should we consider pooling sessions?
> - any way to optimise the session usage given the nodes are all
> read-only?
> If you have no write operations, you can use a single session for the hole
> application(!?)
> All help appreciated.
> Regards,
> Shaun.
>
>
>
> ___________________________________________________________
> All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect
> you. http://uk.docs.yahoo.com/nowyoucan.html
>
>
--
View this message in context: http://www.nabble.com/Profiling-shows-Session-management-to-be-a-hotspot---session-pooling-etc-tf3472134.html#a9690383
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Model 2 deployments on Tomcat: Ensure logging is explicitly disabled
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
.....following on from my email titled "Profiling shows Session management to
be a hotspot - session pooling etc"
After further analysis a lot the CPU time was spent in
PropertyId.toString().
This was called by various blocks surronded by "if (log.isDebugEnabled())"
within JackRabbit. When using a Model 2 deployment with the JackRabbit Jars
within Tomcat common/lib be aware that you need to explicitly ensure that
logging is disabled (even though I'm not seeing debug in any logs).
So by adding a log4j.xml to Tomcat common/classes with a <root> appender set
to WARN this bottle neck has improved.
releaseSession() is now 1.7% of CPU time instead of 11.4%.
My comment on pooling sessions still stands though.
Regards,
Shaun.
-----Original Message-----
From: Shaun Barriball [mailto:sbarriba@yahoo.co.uk]
Sent: 27 March 2007 11:06
To: users@jackrabbit.apache.org
Subject: Profiling shows Session management to be a hotspot - session
pooling etc
Hi all,
We're currently CPU profiling an application which uses the SessionInView
pattern to create a new JCR session (with JackRabbit) for each request.
Profiling shows that around:
- 11.4% of the CPU time is in releaseSession(). In particular around 5% of
this is in ItemManager.evictItem().
- 0.08% of the CPU time is in getSession()
For each request the application is just reading a set of nodes (upto around
100) to generate a web page. We're using JackRabbit 1.2.1 with Oracle.
Any recommendations for how to resolve this overhead?
- should we consider pooling sessions?
- any way to optimise the session usage given the nodes are all read-only?
All help appreciated.
Regards,
Shaun.
___________________________________________________________
All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect
you. http://uk.docs.yahoo.com/nowyoucan.html
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html