ISMLocking in two nodes cluster

[alex marina <al...@yahoo.com>]

Hi guys,
I want to accomplish concurrency control in a two nodes cluster deployment of jackrabbit. I use FineGrainedISMLocking at the workspace and versioning level in the configuration file, but it seems that is not working (on jackrabbit 1.5.5 or 1.6.4).
Is there any other config that should be applied or is there any known issue?
Thank you,Alex


      

Re: ISMLocking in two nodes cluster

[Jukka Zitting <jz...@adobe.com>]

Hi,

On 02/22/2011 01:29 PM, John Langley wrote:
> As some background, I was able to push 2.2.4 to around 500
> concurrent threads (via a jmeter load generator) and it held up
> pretty well, whereas 2.1.4-SNAPSHOT is having problems around 100
> concurrent threads/requests I still have to dig into.

We did quite a bit of concurrent performance work for 2.2, so that's
definitely the version you want to use for concurrent workloads.

> By the way, I still haven't gotten 2 nodes simultaneously updating
> the same db w/out problems,

The current clustering architecture in Jackrabbit is optimized heavily 
optimized for read use case like the ones you'd typically see in a CMS 
backing a public web site. The downside of the current architecture is 
that all clustered writes are synchronized using a global cluster write 
lock, so while read concurrency goes up nearly linearly with more 
cluster nodes write performance remains constant or even degrades a bit 
the bigger your cluster is.

-- 
Jukka Zitting

Re: ISMLocking in two nodes cluster

[alex marina <al...@yahoo.com>]

Hi John,
Thank you for your answer.
The problem is like that: we have a jackrabbit 1.x deployment. Now our client needs to install a jackrabbit cluster. We gave a try and when a node was accessed concurrently from the two nodes we got an Invalid Item State Exception.
We are now trying to use the FineGrainedISMLocking (we also tried DefaultISMLocking) but there seems to be no difference.
Alex

--- On Tue, 2/22/11, John Langley <la...@gmail.com> wrote:

From: John Langley <la...@gmail.com>
Subject: Re: ISMLocking in two nodes cluster
To: users@jackrabbit.apache.org
Date: Tuesday, February 22, 2011, 7:29 AM

jcr-2865 may be the fix you're asking about.

Just FYI, I'm testing 2.1.4-SNAPSHOT as well and there may be issues there
too. Earlier fixes e.g. jcr-2865 made things somewhat better, but as is
typical for performance related issues, it may have just moved the problem.
I'm in the process of exploring.

As some background, I was able to push 2.2.4 to around 500 concurrent
threads (via a jmeter load generator) and it held up pretty well, whereas
2.1.4-SNAPSHOT is having problems around 100 concurrent threads/requests I
still have to dig into.

By the way, I still haven't gotten 2 nodes simultaneously updating the same
db w/out problems, each performance level test I do starts with clustering
enabled but just one node in the cluster (as this triggered the error that
showed in jcr-2865), then I take it to the next level by adding first
another node, and then finally hitting both nodes simultaneously with the
same load generator used to test the single node).

Note: all my testing is in glassfish 2.x with a mysql 5.0 db backend. Be
sure to "balance" your configuration, e.g. never make the number of
connections enabled in your appserver db pool greater than the number of max
connections supported by your db, this will cause you grief.

-- Langley

On Tue, Feb 22, 2011 at 5:40 AM, alex marina <al...@yahoo.com>wrote:

> Hi guys,
> I want to accomplish concurrency control in a two nodes cluster deployment
> of jackrabbit. I use FineGrainedISMLocking at the workspace and versioning
> level in the configuration file, but it seems that is not working (on
> jackrabbit 1.5.5 or 1.6.4).
> Is there any other config that should be applied or is there any known
> issue?
> Thank you,Alex
>
>
>



      

Re: ISMLocking in two nodes cluster

[John Langley <la...@gmail.com>]

jcr-2865 may be the fix you're asking about.

Just FYI, I'm testing 2.1.4-SNAPSHOT as well and there may be issues there
too. Earlier fixes e.g. jcr-2865 made things somewhat better, but as is
typical for performance related issues, it may have just moved the problem.
I'm in the process of exploring.

As some background, I was able to push 2.2.4 to around 500 concurrent
threads (via a jmeter load generator) and it held up pretty well, whereas
2.1.4-SNAPSHOT is having problems around 100 concurrent threads/requests I
still have to dig into.

By the way, I still haven't gotten 2 nodes simultaneously updating the same
db w/out problems, each performance level test I do starts with clustering
enabled but just one node in the cluster (as this triggered the error that
showed in jcr-2865), then I take it to the next level by adding first
another node, and then finally hitting both nodes simultaneously with the
same load generator used to test the single node).

Note: all my testing is in glassfish 2.x with a mysql 5.0 db backend. Be
sure to "balance" your configuration, e.g. never make the number of
connections enabled in your appserver db pool greater than the number of max
connections supported by your db, this will cause you grief.

-- Langley

On Tue, Feb 22, 2011 at 5:40 AM, alex marina <al...@yahoo.com>wrote:

> Hi guys,
> I want to accomplish concurrency control in a two nodes cluster deployment
> of jackrabbit. I use FineGrainedISMLocking at the workspace and versioning
> level in the configuration file, but it seems that is not working (on
> jackrabbit 1.5.5 or 1.6.4).
> Is there any other config that should be applied or is there any known
> issue?
> Thank you,Alex
>
>
>