First of all thanks a lot. Most of my questions were covered. Please check my comments below:
> -----Original Message----- > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] > Sent: Friday, June 09, 2006 5:41 PM > To: [email protected] > 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: [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 > > > 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
