jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Preater" <shane.prea...@googlemail.com>
Subject Re: Possible deadlock of jcr-server 1.2.1 (rmi)
Date Tue, 13 Mar 2007 19:03:43 GMT
Sorry for the post spam there I was trying to forward this to my systems
team as we are seeing something quite similar.

Shane.

On 13/03/07, Shane Preater <shane.preater@googlemail.com> wrote:
>
> Does this sound familiar!
>
> ---------- Forwarded message ----------
> From: Olivier Dony <olivier.dony@denali.be >
> Date: 13-Mar-2007 17:19
> Subject: Possible deadlock of jcr-server 1.2.1 (rmi)
> To: dev@jackrabbit.apache.org
>
> Hi,
>
> We are using the Repository Server deployment model for one of our
> systems, with 3 different web applications using the same jackrabbit
> server.
> Each webapp is running in a separate Tomcat5 server, and jackrabbit
> 1.2.1 is running as a jcr server in a 3rd Tomcat server.
>
> Everything has been doing fine for weeks, but yesterday the
> jackrabbit server suddenly stopped responding to all requests,
> seemingly deadlocked.
> We had the opportunity to take a threadump of the jackrabbit server
> before performing an emergency restart, which solved the situation.
>
> The thread dump is attached. I tried to make some sense out of it,
> but the read/write locks are hard to follow.
> Looks like all RMI-handling thread are waiting to acquire a reader
> lock on the SharedItemStateManager, except one which is waiting for a
> writer lock.
> None appear to be ready to release a lock, which is why I suppose
> they were deadlocked.
>
> Is this maybe related to a lock that isn't reentrant but should be?
> Or not?
> Can anybody see anything there?
>
> Thanks a lot for having a look!
>
>
>
>
>
>
>
> --
> Olivier Dony
>
> Denali s.a., "Bridging the gap between Business and IT"
> Rue de Clairvaux 8, B-1348 Louvain-la-Neuve, Belgium
> Office: +32 10 43 99 51  Fax: +32 10 43 99 52
> www.denali.be
>
> Legal Notice: This message may contain confidential and/or privileged
> information. If you are not the addressee or authorized to receive
> this for the addressee, you must not use, copy, disclose or take any
> action based on this message or any information herein. If you have
> received this message by mistake, please advise the sender
> immediately by return e-mail and delete this message from your
> system. Thank you for your cooperation.
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message