jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jzitt...@adobe.com>
Subject RE: Jackrabbit performance in multi threaded environment
Date Wed, 10 Nov 2010 20:32:33 GMT
Hi,

From: kazim_ssuet@yahoo.com [mailto:kazim_ssuet@yahoo.com]
> Initially I was loggin into repository with adminId/admin for
> all requests and there was deadlock for all threads so nothing
> was moving.

Can you reproduce the deadlock? Please file a bug report about that and attach a thread dump
that shows the deadlock.

The most likely cause of deadlocks in such scenarios is if you're using the same session concurrently
from multiple threads (we've added protection against that in 2.2), but if I understood correctly
this is not the case here.

> Then I changed the login so only threads that need to modify
> properties or load documents are logging in as admin and rest
> are logging as anonimous (read only mode), things started moving
> but still performance decreases alot when threads count is
> increased. Even only 10 threads of each operation (load, fetch,
> modify) take alot of toll on performance.

The Jackrabbit 2.1 (and older) architecture is optimized for the case where most concurrent
reads access already cached content. Write operations and reads that access the underlying
hard disk end up blocking all other repository access, which explains the performance loss
you're seeing.

We've made some significant improvements for concurrent read operations in Jackrabbit 2.2
(most notably a cache miss will no longer block other readers), but write operations still
require exclusive access. The optional FineGrainedISMLocking strategy can be used to avoid
this exclusive lock when dealing with non-overlapping parts of the content tree.

BR,

Jukka Zitting
Mime
View raw message