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 <[email protected]>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 > > >
