cancel
Showing results for 
Search instead for 
Did you mean: 

When should NodeStatus (alf_node_status table) be updated?

francescof
Champ in-the-making
Champ in-the-making
I'm asking the question "when should NodeStatus (alf_node_status table) be updated?" because I ran in the same problem two times in a few days.

The first is described here: http://forums.alfresco.com/viewtopic.php?t=8772

The second is similar, and has a similar solution…

I noticed that, in a two node clustered environment, if I update properties on a node calling setProperties() API from NodeService, the results from a XPath/Lucene search on the remote node (with respect to the node where the change was performed) don't reflect the new value.

Example:
    * Content cm:foo has cm:author = Alice.
    * Call setProperties() on node 1 to set cm:author = Bob on content cm:Foo.
    * getProperties() on XPath/Lucene search results on node 1 shows cm:author = Bob, on node 2 shows cm:author = Alice.
    * Web client "show details" on cm:Foo shows cm:author = Bob on both nodes.
Looking through the code in DbNodeServiceImpl I noticed that setPropertiesImpl() calls nodeDaoService.recordChangeId(nodeRef).

From HibernateNodeDaoServiceImpl.java:

    public void recordChangeId(NodeRef nodeRef)
    {
        NodeKey key = new NodeKey(nodeRef);
       
        NodeStatus status = (NodeStatus) getHibernateTemplate().get(NodeStatusImpl.class, key);
        if (status == null)
        {
            // the node never existed or the status was deleted
            return;
        }
        else
        {
            // make sure that the status has the latest transaction attached
            Transaction currentTxn = getCurrentTransaction();
            status.setTransaction(currentTxn);
        }
    }

But this is not sufficient to force a node reindex on the remote node. I added the following line after status.setTransaction(currentTxn):


    getHibernateTemplate().saveOrUpdate(status);

Now I can see the updates on both nodes. Once again I'm asking if this change is likely to break other things.

What's your opinion?
2 REPLIES 2

andy
Champ on-the-rise
Champ on-the-rise
Hi

The lucene indexes on the two nodes will be tracking the changes made by the other. The changes are not indexed atomically over the cluster. XPath goes against the node service/DB so should be correct if your clustred cache configuration is correct.

You can configure how aggressive the tracking job is at keeping up to date.

Support to share the lucene index is on going. This will remove this issue.

Andy

francescof
Champ in-the-making
Champ in-the-making
What I noticed is that, on 2.1, XPath goes on Lucene and selectNodes() goes on Jaxen XPath so it really was a matter of indexes not being updated.

I've applied manually the fixes related to JIRA AR-1777 but it seems that the remote node still doesn't update its indexes. Adding a call to getHibernateTemplate().saveOrUpdate(status) in the else block in HibernateNodeDaoServiceImpl.recordChangeId() seems to do the trick.

Bye.
Getting started

Tags


Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.