Re: Jackrabbit 1.6.4 locking issue

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Jan 5, 2011 at 9:16 PM, shailesh mangal
<sh...@getzephyr.com> wrote:
> Unfortunately issue still exists, even after we moved to 2.2.

Do you still see this problem in your deployment?

I found a somewhat similar (though not exactly the same) deadlock
scenario with the latest trunk, see JCR-890 [1]. It would be great if
you could check if the stacktraces match your case.

I don't believe the original deadlock case described for 1.6.4 can
occur anymore in 2.2.

[1] https://issues.apache.org/jira/browse/JCR-2890

BR,

Jukka Zitting

Re: Jackrabbit 1.6.4 locking issue

[luciano favaro <lu...@gmail.com>]

Hi Guys, I'm facing similar problem, since I have a custom login module that
uses same systemsession on all .login, do you have any update on this issue?

Thanks,
Luciano



--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-1-6-4-locking-issue-tp3134490p4658778.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: Jackrabbit 1.6.4 locking issue

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

Hi,

On 02/14/2011 10:40 AM, Raj wrote:
> The stack traces match a lot, I strongly believe it may be same issue.

OK, thanks for the verification!

> Please let me know if this bug could be addressed soon.
> I would love to try any fixes in my setup.

Excellent, thanks. I'll see what we can do about this on a short notice.

This deadlock is related to security code and synchronization of 
concurrent sessions, both of which are areas on which we have been 
working with for Jackrabbit 2.2. One thing you might want to try is 
switching back to 2.1 to see if this deadlock also occurs there.

Also, it would be perfect if you could somehow narrow down the deadlock 
you're seeing into a standalone test case. I currently don't have a way 
to reliably reproduce the issue locally, which makes it harder to fix it.

-- 
Jukka Zitting

Re: Jackrabbit 1.6.4 locking issue

[Raj <db...@gmail.com>]

hi Jukka,

Thanks for your reply.

The stack traces match a lot, I strongly believe it may be same issue.
Our setup doesn't use lucene and acl and we use workspace.copy, so stack
traces won't match perfectly and jackrabbit versions are different too.

Ignoring bottom 3-4 items in my stack trace, it appears control flow seems
to be taking identical steps.

Thread 19 -> matches stack trace A (as per bug report)
Thread 18 -> matches B
Thread 25 -> matches C

Please let me know if this bug could be addressed soon.
I would love to try any fixes in my setup.

thanks for your help.

cheers,
Rajeev

On Fri, Feb 11, 2011 at 11:52 PM, Jukka Zitting <ju...@gmail.com>wrote:

> Hi,
>
> On Wed, Jan 5, 2011 at 9:16 PM, shailesh mangal
> <sh...@getzephyr.com> wrote:
> > Unfortunately issue still exists, even after we moved to 2.2.
>
> Do you still see this problem in your deployment?
>
> I found a somewhat similar (though not exactly the same) deadlock
> scenario with the latest trunk, see JCR-890 [1]. It would be great if
> you could check if the stacktraces match your case.
>
> I don't believe the original deadlock case described for 1.6.4 can
> occur anymore in 2.2.
>
> [1] https://issues.apache.org/jira/browse/JCR-2890
>
> BR,
>
> Jukka Zitting
>