Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mreutegg@gmail.com designates
 66.249.82.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=utPLjCbrjs5qQdYCkTBTo1wjxDC4ZuCZUI0YPFoVeSRON4bMZrqMJABZNZcKRmhbk7GL6fnKTOxO5LVA+V9hCXElHjiKVZBZ2HdEQbKYEy9P3OsyUxXGbzWhOKrbum/DFaTdprp3tMzTdVSscXgts/xgIRv4PatHuLVS2jermNg=
Message-ID: <d97b4c170606142341g260db424ia6386dcd6fc47b01@mail.gmail.com>
Date: Thu, 15 Jun 2006 08:41:18 +0200
From: "Marcel Reutegger" <marcel.reutegger@day.com>
Sender: mreutegg@gmail.com
To: dev@jackrabbit.apache.org
Subject: Re: jackrabbit & clustering
In-Reply-To: <02d101c68bdb$712d4a10$b6fdfe0a@gkaradimitr>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44898890.9060903@gmx.net>
	 <02d101c68bdb$712d4a10$b6fdfe0a@gkaradimitr>

Hi Giota,

On 6/9/06, Giota Karadimitriou <Giota.Karadimitriou@eurodyn.com> wrote:
> I have this method in order to enforce same order between the 2 nodes
>
> private void acquireDistributedWriteLock() throws ItemStateException {
>        String ip = null;
>
>        try {
>            ip = InetAddress.getLocalHost().getHostAddress();
>        } catch (UnknownHostException e) {
>            log.error("Could not find IP address");
>        }
>
>        if (ip.equals(ip1)) {
>            log.debug("acquire write lock on 1");
>            acquireWriteLock();
>        }
>        try {
>            if (sismRemote==null) sismRemote=getRemoteSharedManager();
>            log.debug("acquire write lock on
> "+(ip.equals(ip1)?"2":"1"));
>            if (sismRemote!=null) sismRemote.acquireWriteLock();
>        } catch (Exception ee) {
>            log.error(ee.getMessage());
>        }
>        if (ip.equals(ip2)) {
>            log.debug("acquire write lock on 2");
>            acquireWriteLock();
>        }
>
>    }
>
> this method is only called within Update.begin()
>
> public void begin() throws ItemStateException,
> ReferentialIntegrityException {
>            shared = new ChangeLog();
>
>            virtualNodeReferences = new List[virtualProviders.length];
>
>            acquireDistributedWriteLock();
> ...
> }
>
> It should print
> >>>  09/06/2006 17:15:25.052
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 1
> >>>  09/06/2006 17:15:25.067
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 2
>
> and instead I get
> DEBUG org.apache.jackrabbit.core.state.NodeState - listener already
> registered: org.apache.jackrabbit.core.CachingHierarchyManager@47283
> >>>  09/06/2006 17:15:25.052
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 1
> >>>  09/06/2006 17:15:25.067
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 2
> >>>  09/06/2006 17:15:25.098
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 1
> >>>  09/06/2006 17:15:25.098
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - acquire write
> lock on 2
> >>>  09/06/2006 17:15:25.130
> [AJPRequestHandler-ApplicationServerThread-9] [9) 10.254.253.182
> CDSManager1 09/06/2006_9] DEBUG
> org.apache.jackrabbit.core.state.SharedItemStateManager - persisting
> change log {#addedStates=9, #modifiedStates=1, #deletedStates=0,
> #modifiedRefs=0} took 16ms

I'm not sure, but maybe what you see is the SISM lock of the version
storage. as I mentioned before a stacktrace with the debug log message
would indicate where the call is originated.

> > do you mean connections that are used by the persistence managers?
>
> Yes, I use SimpleDBPersistenceManager and so far (before clustering
> attempt) things were working fine but now that I use this EJB to contact
> the other shism (on the other cluster) within Update.end(), after a
> while I start getting transaction incomplete exceptions and connections
> exhausted exceptions;

well, it's difficult to help you here. I guess you have to debug your
jackrabbit mod to see where the connections are lost (or kept).

regards
 marcel