Re: jackrabbit & clustering

[Marcel Reutegger]

Hi Giota,

On 6/9/06, Giota Karadimitriou <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>>  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