Hi,
Seems like another case of the age-old JCR-18 issue with concurrent
versioning. Both of the updates contain some versioning operations,
and since concurrent versioning is at the moment still a rather
dangerous sport, I'm not surprised if bad things like a deadlock can
occur.
Any
Hi Savas,
Savas Triantafillou wrote:
the whole directory... not only indeces...
if you were more specific this would be a lot easier :-/
I asked about the exact directories you deleted. but anyway...
if you delete the whole 'repository home' directory, all data is removed and you
will
We've been aware of this issue for a while. Unfortunately, the locking
implementation is pretty hard to disentangle, and we haven't been able
to come up with a fix. However, we have been able to work around it by
adding an extra level of synchronisation in our own application that
ensures only
Hi,
On 3/14/07, Tobias Bocanegra [EMAIL PROTECTED] wrote:
imo, we can't fixed the transaction/concurrency issues that occur
together with versioning without a bigger redesign of some of the core
parts of jackrabbit.
Do we have some directions that seem worth pursuing? Would rethinking
the
imo, we can't fixed the transaction/concurrency issues that occur
together with versioning without a bigger redesign of some of the core
parts of jackrabbit.
Do we have some directions that seem worth pursuing? Would rethinking
the locking mechanisms be enough, or do we need to fundamentally
On 3/14/07, Marcel Reutegger [EMAIL PROTECTED] wrote:
Hi Savas,
Savas Triantafillou wrote:
the whole directory... not only indeces...
if you were more specific this would be a lot easier :-/
I asked about the exact directories you deleted. but anyway...
if you delete the whole 'repository
Possible deadlock during concurrent operations on versionable nodes
---
Key: JCR-790
URL: https://issues.apache.org/jira/browse/JCR-790
Project: Jackrabbit
Issue Type: Bug
[
https://issues.apache.org/jira/browse/JCR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Dony updated JCR-790:
-
Attachment: jackrabbit-thread-dump.log.zip
This is the (huge) thread dump of the deadlock situation.
[
https://issues.apache.org/jira/browse/JCR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Dony updated JCR-790:
-
Attachment: thread-dump-analysis.txt.zip
This is the analysis of the locking performed by the 2 deadlocked
David Johnson wrote:
While I can see how my suggested optimization could severely impact some
use
cases. Nevertheless, our use case :-) is mostly querying a stable
hierarchy structure - i.e., we rarely, if ever, would move a tree with even
1000s of sub-nodes (famous last words). And we use
Hi,
For the record I've created JCR-790 and attached the thread dump and
Marcel's lock explanation.
Miro's workaround of putting an additional level of synchronization
on all write operations on the repository is not quite suitable in
our case. Not only because of the performance hit,
Christoph Kiehl wrote:
Christoph Kiehl wrote:
I was digging a bit into Jackrabbit today and found another place
where some caching did provide a substantial performance gain to
queries which check one attribute for more than one value (like
/foo/[EMAIL PROTECTED]:bar='john' or
Cache BitSet per IndexReader in MatchAllScorer
--
Key: JCR-791
URL: https://issues.apache.org/jira/browse/JCR-791
Project: Jackrabbit
Issue Type: Improvement
Components: query
Jukka Zitting wrote:
Do we have some directions that seem worth pursuing? Would rethinking
the locking mechanisms be enough, or do we need to fundamentally
modify the basic ItemStateManager and VersionManager designs?
I haven't thought about this in much detail, but IMO the sequence how locks
Savas Triantafillou wrote:
What I did was to delete the whole repository home directory that is both
the 'repository' and 'workpaces'
directories
This means you deleted *all* content in your repository. In that case there's
nothing you can query for, unless you add content again.
regards
Hi David,
I was mainly interested in the size of the repository and the structure, just
like you described it.
Another aspect that affects query performance is the complexity of the query.
What's the structure of your queries?
Are they simple? e.g.: //element(*, my:content)[EMAIL
Hi,
On 3/14/07, Marcel Reutegger [EMAIL PROTECTED] wrote:
it's not fully synchronized, queries do run in parallel, which can be seen in
Davids results. but at a lower level, probably in lucene, some part of the query
execution is synchronized.
Other potential issues are, as already suggested,
Marcel Reutegger wrote:
Christoph Kiehl wrote:
Christoph Kiehl wrote:
I was digging a bit into Jackrabbit today and found another place
where some caching did provide a substantial performance gain to
queries which check one attribute for more than one value (like
/foo/[EMAIL
[
https://issues.apache.org/jira/browse/JCR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480788
]
Dominique Pfister commented on JCR-769:
---
As you correctly identified, if there are two sessions (or branches)
Hi,
I noticed that the Session implementations both in Jackrabbit and
JCR2SPI require that the Credentials object passed into the
impersonate() method actually is a SimpleCredentials object. The purpose
seems to be that the impersonating session can be remembered in an
attribute on the
[
https://issues.apache.org/jira/browse/JCR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480812
]
Claus Köll commented on JCR-769:
I have not sayed that i have fixed the problem only with the fact of changing
the
[
https://issues.apache.org/jira/browse/JCR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480807
]
Dominique Pfister commented on JCR-769:
---
Sorry for introducing TX2B2 which should be TX1B2, of course. IMO, it
Hi Christoph,
Christoph Kiehl wrote:
I've created a jira issue: http://issues.apache.org/jira/browse/JCR-791
Are you working on this issue? Or should I try to implement something?
I just started working on it ;)
Actually it's /foo/[EMAIL PROTECTED]:bar!='john']
ah, yes. that makes
[
https://issues.apache.org/jira/browse/JCR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480844
]
Dominique Pfister commented on JCR-769:
---
I have not sayed that i have fixed the problem only with the fact of
Marcel Reutegger wrote:
Christoph Kiehl wrote:
I've created a jira issue: http://issues.apache.org/jira/browse/JCR-791
Are you working on this issue? Or should I try to implement something?
I just started working on it ;)
Great news ;)
Now that you are working on implementing this cache
Both of these proposals sound great - particularly the additional caching in
DescendantSelfAxisQuery. I think this would address the scenario that I
suggested additional indexing earlier in this thread. As I mentioned, in my
query test set DescendantSelfAxisQuery.DescendantSelfAxisScorer.next()
after enabling access manager, I can't createNode and setProperty without a
node.save in the middle
---
Key: JCR-792
URL:
I have 5-7 stack dumps from 2 different runs that I captured using jstack.
Here is an interesting (in that there are 2 blocked threads) example - I
have many more, and can create many more as needed - I was running a 4
thread test corresponding to the # of cores on my system. I ran another
test
Hi,
I'm thinking of attending the ApacheCon Europe this year. Is anyone besides
Jukka going there?
Cheers,
Christoph
ps: I hope it's okay to post this to the developer list
On 3/14/07, Christoph Kiehl [EMAIL PROTECTED] wrote:
Hi,
I'm thinking of attending the ApacheCon Europe this year. Is anyone besides
Jukka going there?
i'll be there
ps: I hope it's okay to post this to the developer list
of course :-)
- robert
Tobias,
We are also experiencing this problem with deadlocks on our system could you
outline the hacks you have used to fix this issue. We are using versioning
in a production environment so if we need to hack it temporarily to get over
this issue then so be it for the moment.
Also I will keep
31 matches
Mail list logo
