You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by sbarriba <sb...@yahoo.co.uk> on 2008/01/05 16:37:48 UTC
RE: Shared session pool
Hi Andrea,
We use an "Open Session In View" pattern with Jackrabbit and
org.apache.commons.pool.KeyedObjectPool.
Within a Filter:
* we determine the context workspace name from the request (based on the
URL)
* retrieve a JCR session from the pool
* bind it to the thread for the duration of the request and
* then return it to the pool again after the request completes.
This has worked well for us. Hope this helps.
Regards,
Shaun
-----Original Message-----
From: Andrea K. [mailto:akregar@alteanet.it]
Sent: 24 December 2007 10:47
To: users@jackrabbit.apache.org
Subject: Shared session pool
Hi all,
I want to start a thread concerning forum users experience with session pool
in (web) apps using JR.
I read about many users are using pools in their applications.
Does anyone want to share his knowledge/code?
Thank you all.
Best regards and Merry Christmas.
AK.
--
View this message in context:
http://www.nabble.com/Shared-session-pool-tp14486499p14486499.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Hi,
this property is intended a wait timeout for what in particular?
<property name="waitTimeout" value="0" />
Is from an oc4-ja.ra JCA connector configuration xml.
Thanks a lot.
BR.
Andrea -
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14686123.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Shared session pool
Posted by ben short <ja...@gmail.com>.
You might want to look at the apache commons pool [1] instead of
rolling your own.
[1] http://commons.apache.org/pool/
On Jan 9, 2008 9:59 AM, Andrea K. <ak...@alteanet.it> wrote:
>
>
> Hi Alex,
> I attached the code. As you can see is not complex.
> Logout are never done for readonly sessions, but only for admin (write)
> operations.
> Every X minutes sessionpool is purged and new sessions are created. Obsolete
> sessions are logged out or expire automatically.
>
> Thanks a lot for your help.
> BR.
> A. - http://www.nabble.com/file/p14707938/session_pool.java
> session_pool.java
> --
> View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14707938.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Hi Alex,
> Andrea, I must confess that I haven't got the time too fully look
> through your code. Moreover it is not immediately clear how it gets
> called, as the class is offering only a get operation and not a
> release as normal pools.
This is the code used to call the pool:
...
RepositoryManager rm = new RepositoryManager();
Session session = rm.getSession(this.getHttpsession());
...
and then in RepositoryManager:
...
if (user.getJcrUsername().equalsIgnoreCase("ANONYMOUS")) {
session =
JcrSessionPool.getConnectionPool().getSession(workspace, httpsession);
}
...
and the logout method (effectively never done because of anonymous user)
...
JcrSessionPool.getConnectionPool().sessionLogout(session, getHttpsession());
...
in this case, if you are an admin, logout is effective because of session is
dedicated
and not taken by the pool, but singular in this way:
...
repository = (Repository)context.lookup("jcr/repo");
SimpleCredentials cred = new SimpleCredentials(username,
password.toCharArray());
session = repository.login(cred, workspace);
return session;
...
> But, if you are invoking this code on each HTTP request, then I would
> say that you really have a big bottleneck in your app and you should
> try to get rid of it (synchronization at the level of your pool,
> synchronization at the level of collections). My whole heartly advise
> would be to look into an existing pooling solution (even if a generic
> one) and try to use it. Without any intentions to criticize your code,
> most probably an existing solution would have already been passing
> through testing and different scenario usages that are making it a bit
> more stable and reliable than your home made pool (I really hope you
> are not getting this the wrong way).
No problem at all Alex. I have to say that I tested the app with load
testers and it worked well.
And.. during tests, I have no locks at all... It happens randomly on a
clustered version of the app
after several hours of use. Talking about using another pool, I can stay
with you. But the point is
to understand why this pool is locking. No error are catched in the class i
sent, no errors at all...
No new sessions are created in getSession method except when
sessionPoolCleaner is called.
So I can say that it could happen also with others pools?
Version used is JR 1.3.1 patched with JCR-905 patch for clustered
enviroments.
Could be a problem linked to wait locks? No waitTimeout is defined in JCA
connector configuration, so...
Or could be a deadlock problem related to itemCache, JCR-862 for example?
Do you think that let synchronized only the class and not method could be
correct and more fast?
Another point, workspaces are fully working accessed with
Does anyone can help or address me to a solution or a real-life (code)
solution?
Thanks a lot.
BR.
Andrea -
> bests,
> ./alex
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14729813.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Shared session pool
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On Jan 9, 2008 11:22 AM, Andrea K. <ak...@alteanet.it> wrote:
>
> Hi Alex,
> I attached the code. As you can see is not complex.
> Logout are never done for readonly sessions, but only for admin (write)
> operations.
> Every X minutes sessionpool is purged and new sessions are created. Obsolete
> sessions are logged out or expire automatically.
>
> Thanks a lot for your help.
> BR.
> A. - http://www.nabble.com/file/p14707938/session_pool.java
> session_pool.java
Andrea, I must confess that I haven't got the time too fully look
through your code. Moreover it is not immediately clear how it gets
called, as the class is offering only a get operation and not a
release as normal pools.
But, if you are invoking this code on each HTTP request, then I would
say that you really have a big bottleneck in your app and you should
try to get rid of it (synchronization at the level of your pool,
synchronization at the level of collections). My whole heartly advise
would be to look into an existing pooling solution (even if a generic
one) and try to use it. Without any intentions to criticize your code,
most probably an existing solution would have already been passing
through testing and different scenario usages that are making it a bit
more stable and reliable than your home made pool (I really hope you
are not getting this the wrong way).
bests,
./alex
--
.w( the_mindstorm )p.
> --
> View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14707938.html
>
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Hi Alex,
I attached the code. As you can see is not complex.
Logout are never done for readonly sessions, but only for admin (write)
operations.
Every X minutes sessionpool is purged and new sessions are created. Obsolete
sessions are logged out or expire automatically.
Thanks a lot for your help.
BR.
A. - http://www.nabble.com/file/p14707938/session_pool.java
session_pool.java
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14707938.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Shared session pool
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On Jan 8, 2008 11:51 PM, Andrea K. <ak...@alteanet.it> wrote:
>
> Thanks for your reply Alex.
>
> Now, as I've said, I'm using 15 session shared to access each workspace.
> Everything work well, except sometimes the pool seems to hang up, and as
> methods are syncronized, app is blocked. I have no errors in logs
> (application or repository) and so is difficult to find the problem.
> Have you any idea?
>
Andrea, I cannot say that I'm a concurrency expert, but without seeing
some code it is even harder :-).
I suspect the problem is caused by the synchronization and the fact
that you perform those login/logouts.
> I have no waitTimeout in connector configuration (now is = 0).
> Do you think it could be better to setup the value to at least 180 seconds?
>
I am not sure what you are referring to here.
./alex
--
.w( the_mindstorm )p.
> It's a big problem and any help is appreciated...
>
> Could be linked to sessions that read many binaries from repostory?
>
> I can send the poll code if you want...
>
> Thanks a lot...
>
> BR,
> AK.
> --
> View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14699673.html
>
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Thanks for your reply Alex.
Now, as I've said, I'm using 15 session shared to access each workspace.
Everything work well, except sometimes the pool seems to hang up, and as
methods are syncronized, app is blocked. I have no errors in logs
(application or repository) and so is difficult to find the problem.
Have you any idea?
I have no waitTimeout in connector configuration (now is = 0).
Do you think it could be better to setup the value to at least 180 seconds?
It's a big problem and any help is appreciated...
Could be linked to sessions that read many binaries from repostory?
I can send the poll code if you want...
Thanks a lot...
BR,
AK.
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14699673.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Shared session pool
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On Jan 8, 2008 3:25 PM, Andrea K. <ak...@alteanet.it> wrote:
>
> Hi Alex,
> shared sessions are used only for readonly requests. I shared them because
> of their use.
> It's a web application and requests are various and from various points
> inside app.
> So, many logins and logouts are frequently done, and that the point that
> made me decide to
> share sessions. Also various forum posts talk about this appointing to
> divide readonly session
> from write sessions. Consequently, write operations are managed from another
> web applications and use their own sessions. Nothing is shared when writing.
>
> Any critique is appreciated!
>
> BR,
> Andrea -
>
Thanks for the clarifications Andrea. As I've said with read only
sessions your approach makes a bit more sense (and probably I got
confused by the synchronized word used in your initial email).
According to your comment, it is the numerous session login/logout
that you've tried to address when sharing the session. But, as far as
I can say: with the pool you login only once per each session
available in the pool (and logout only when you restart the app), so
this cost is completely eliminated. Now, imo it all boils down to
correctly sizing the pool.
As I have researched myself in old versions sharing a read only
session between threads is safe, but as you probably know this is not
guaranteed, so your company should be aware that upon an upgrade the
whole thing may break. I am using a single session shared between
multiple threads myself, and I have warnings everywhere in my app for
this (and due to this and a couple of other dependencies I'm still
stuck with a quite old version).
./alex
--
.w( the_mindstorm )p.
>
> --
> View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14689371.html
>
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Hi Alex,
shared sessions are used only for readonly requests. I shared them because
of their use.
It's a web application and requests are various and from various points
inside app.
So, many logins and logouts are frequently done, and that the point that
made me decide to
share sessions. Also various forum posts talk about this appointing to
divide readonly session
from write sessions. Consequently, write operations are managed from another
web applications and use their own sessions. Nothing is shared when writing.
Any critique is appreciated!
BR,
Andrea -
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14689371.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Shared session pool
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On Jan 8, 2008 11:37 AM, Andrea K. <ak...@alteanet.it> wrote:
>
> Hi Shaun,
> I implemented an easy pool that hold a group of read-only session (15 per
> workspace) and share them to users. A session is not dedicated to a request,
> but is shared for multiple request.
>
> These are actual property in JCA connector xml:
> <property name="waitTimeout" value="0" />
> <property name="scheme" value="dynamic" />
> <property name="maxConnections" value="200" />
> <property name="inactivity-timeout-check" value="all" />
> <property name="minConnections" value="1" />
> <property name="inactivity-timeout" value="900" />
>
> To ensure a polish situation in time, i run a scheduled task that clean the
> pool every 30 min, and recreate 15 new sessions every time. Old sessions are
> logged out or expires automatically. These ensure a correct value of
> CacheManager, normally below 100.
>
> What do you think about that?
>
> It works well, is synchronized obviously, but performance seems to be better
> than dedicated sessions.
>
> Just an issue. Sometimes the pool hang up and I think is linked to dead
> sessions... Now I'm trying controlling also isLive session properties before
> returning to user.
>
> Do you have any help to improve my code?
>
> I can share it if is needed...
>
> Thanks a lot.
>
>
Andrea can you explain why have you decided to have the sessions
shared between the requests and not one session per request? In case
these JCR sessions are used for write operations then you'll need to
synchronize on them and this may become very easily a real bottleneck
of the app.
A share nothing approach (a JCR session per request) combined with a
session pool should give you all you need, and will definitely not
lead to bottlenecks. The worst case scenario is when a request should
be waiting for a session to be freed.
cheers,
./alex
--
.w( the_mindstorm )p.
>
>
> sbarriba wrote:
> >
> > Hi Andrea,
> > We use an "Open Session In View" pattern with Jackrabbit and
> > org.apache.commons.pool.KeyedObjectPool.
> > Within a Filter:
> > * we determine the context workspace name from the request (based on the
> > URL)
> > * retrieve a JCR session from the pool
> > * bind it to the thread for the duration of the request and
> > * then return it to the pool again after the request completes.
> > This has worked well for us. Hope this helps.
> > Regards,
> > Shaun
> >
> > -----Original Message-----
> > From: Andrea K. [mailto:akregar@alteanet.it]
> > Sent: 24 December 2007 10:47
> > To: users@jackrabbit.apache.org
> > Subject: Shared session pool
> >
> >
> > Hi all,
> > I want to start a thread concerning forum users experience with session
> > pool
> > in (web) apps using JR.
> > I read about many users are using pools in their applications.
> >
> > Does anyone want to share his knowledge/code?
> >
> > Thank you all.
> >
> > Best regards and Merry Christmas.
> > AK.
> > --
> > View this message in context:
> > http://www.nabble.com/Shared-session-pool-tp14486499p14486499.html
> > Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14685207.html
>
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
RE: Shared session pool
Posted by "Andrea K." <ak...@alteanet.it>.
Hi Shaun,
I implemented an easy pool that hold a group of read-only session (15 per
workspace) and share them to users. A session is not dedicated to a request,
but is shared for multiple request.
These are actual property in JCA connector xml:
<property name="waitTimeout" value="0" />
<property name="scheme" value="dynamic" />
<property name="maxConnections" value="200" />
<property name="inactivity-timeout-check" value="all" />
<property name="minConnections" value="1" />
<property name="inactivity-timeout" value="900" />
To ensure a polish situation in time, i run a scheduled task that clean the
pool every 30 min, and recreate 15 new sessions every time. Old sessions are
logged out or expires automatically. These ensure a correct value of
CacheManager, normally below 100.
What do you think about that?
It works well, is synchronized obviously, but performance seems to be better
than dedicated sessions.
Just an issue. Sometimes the pool hang up and I think is linked to dead
sessions... Now I'm trying controlling also isLive session properties before
returning to user.
Do you have any help to improve my code?
I can share it if is needed...
Thanks a lot.
sbarriba wrote:
>
> Hi Andrea,
> We use an "Open Session In View" pattern with Jackrabbit and
> org.apache.commons.pool.KeyedObjectPool.
> Within a Filter:
> * we determine the context workspace name from the request (based on the
> URL)
> * retrieve a JCR session from the pool
> * bind it to the thread for the duration of the request and
> * then return it to the pool again after the request completes.
> This has worked well for us. Hope this helps.
> Regards,
> Shaun
>
> -----Original Message-----
> From: Andrea K. [mailto:akregar@alteanet.it]
> Sent: 24 December 2007 10:47
> To: users@jackrabbit.apache.org
> Subject: Shared session pool
>
>
> Hi all,
> I want to start a thread concerning forum users experience with session
> pool
> in (web) apps using JR.
> I read about many users are using pools in their applications.
>
> Does anyone want to share his knowledge/code?
>
> Thank you all.
>
> Best regards and Merry Christmas.
> AK.
> --
> View this message in context:
> http://www.nabble.com/Shared-session-pool-tp14486499p14486499.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
>
--
View this message in context: http://www.nabble.com/Shared-session-pool-tp14486499p14685207.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.