Hi, From: [email protected] [mailto:[email protected]] > 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
