jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Fri, 09 Jun 2006 15:43:23 GMT
First of all thanks a lot. Most of my questions were covered. Please
check my comments below:

> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Friday, June 09, 2006 5:41 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> 
> Giota Karadimitriou wrote:
> > In my previous email, I wrote the scenario that I try to follow
> > regarding clustering; however I feel I am really at zero once again
so
> > could anybody provide me with some conceptual help regarding
clustering
> > aspects because I feel I need to understand the jackrabbit model a
lot
> > more in order to achieve sth:
> >
> > 1)       If someone wanted to share states where would it be the
best
> > place to do it in regards to
> > beginUpdate().end() statement?
> >
> > a)       Inside end(), before downgrading to read lock
> > b)       Inside end() after downgrading to read lock and before
> > events.dispatch
> 
> I'd say the states need to be distributed while holding the write
lock.
> otherwise another cluster node may see inconsistent data.
> 
> > 2)       a) added states: do I need to propagate them or not (will
the
> > second cluster node find them eventually from the database and
upload
> > them into shsim2.cache either way?)
> 
> it depends, if you also want to trigger observation you have to
> propagate added states too. otherwise you are probably fine. but I'm
not
> sure if there are other implications...
> 
> > c)       modified states; what I do is: if they are non-virtual and
they
> > exist on shism2.cache I just empty them from shsim2.cache, for
virtual
> > states, I copy from shism1 and notify
> 
> why isn't the handling the same for all states?

So for non-virtual "notify" and for virtual "copy and notify" or "copy
and notify" for both?

> 
> > d)       deleted states; what I do is: if they are non-virtual and
they
> > exist on shsim2.cache I just empty them from shsim2.cache, otherwise
for
> > virtual states, I just notify
> 
> again, why do you have separate handling for virtual and non-virtual
> states? shouldn't this be the same for both: notify?

> 
> > 3) I put a print statement "acquiring write lock" when acquiring
write
> > lock in SharedItemStateManager, I observed it's being print twice;
why
> > is that since SharedItemStateManager persists changes (to the
database)
> > only once?
> 
> hmmm, don't know. do you have a stacktrace with the log message? that
> probably helps.
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



> 
> > 3)       Distributed read locks; do you think they are necessary ?
> 
> now that you mention it... I think you should be just fine without
them.
> I don't see a reason right now why you need them...
> 
> > 4)       To propagate the states I call an EJB from our application
> > which connects to the SharedItemStateManager of the other node
> >
> > using
> >
> > RepositoryImpl repImpl =
> >             ((JCARepositoryHandle) repository).getRepositoryImpl();
> >         SharedItemStateManager sism =
> >             repImpl.getWorkspaceStateManager("default");
> >
> > This is a terrible approach since I added a
> >
> > -public Repository getRepositoryImpl()  method in
JCARepositoryHandle
> >
> > -and I made RepositoryImpl.getWorkspaceStateManager public also
> >
> > but I could think of no other way to retrieve access the
> > sharedItemstatemanager of the other cluster node.
> > I know that shared item state manager is supposed not to be visible
but
> > I must make it visible in order to share the states.
> >
> > Is there some easier way?
> 
> well, I guess that's currently the only 'way'. Jackrabbit as it is
right
> now just does not provide access to the SharedISM because it is
> considered internal.
> 
> > 5)       What additional things will be needed for "versioning"?
> 
> I assume it is similar to regular workspace content. at its bottom
there
> is a SharedISM as well. But I don't know the details there...
> 
> > 6)       Connections seem to be exhausted after a while; why could
that
> > be?
> 
> do you mean connections that is 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; 


> 
> regards
>   marcel


Mime
View raw message