Node Reference Retrieval Issues and XPath Issues in Alfresco 7.4 / Solr6 Kubernetes Deployment

cancel
Showing results for 
Search instead for 
Did you mean: 
cjbautista
Customer

Node Reference Retrieval Issues and XPath Issues in Alfresco 7.4 / Solr6 Kubernetes Deployment

I'm encountering issues with Node References and XPath searches after migrating to Alfresco 7.4 running on Kubernetes with Solr6.

Node Reference Issue: In my Java code, methods for retrieving Node References are working correctly in my local testing environment. However, when deployed to Kubernetes, these methods return NULL. XPath Issue: The Node Browser fails to find the Company Home node using XPath searches in the Kubernetes environment.

Environment:

Alfresco 7.4 Solr6 Kubernetes

Troubleshooting Steps Taken:

Solr Reindex: I've fully reindexed the Solr search container. Local Verification: Confirmed functionality in a local test environment. Basic Searches: General searches seem to return files as expected.

Logs show this:

2024-02-13T19:32:00,150 [] ERROR [quartz.core.JobRunShell] [DefaultScheduler_Worker-4] Job jobGroup.filingScheduledActionCronJob threw an unhandled Exception:
java.lang.NullPointerException: Cannot invoke "org.alfresco.service.cmr.repository.NodeRef.getStoreRef()" because "nodeRef" is null

Methods

private NodeRef getNodeByPath(final String nodePath) {
        final String escNodePath = nodePath.replace(" ", "_x0020_");
        StoreRef storeRef = new StoreRef(StoreRef.PROTOCOL_WORKSPACE, "SpacesStore");
        final String query = "PATH:\"" + escNodePath + "\"";
        ResultSet rs = serviceRegistry.getSearchService().query(storeRef, SearchService.LANGUAGE_LUCENE, query);
        NodeRef nodeRef = null;
        try {
            if (rs.length() == 0) {
                return null;
            }
            nodeRef = rs.getNodeRef(0);
            return nodeRef;
        } finally {
            rs.close();
        }
    }
    public NodeRef getCompanyHome() {
        NodeRef nodeRef = null;
        ResultSet rs = serviceRegistry.getSearchService().query(
                new StoreRef(StoreRef.PROTOCOL_WORKSPACE, "SpacesStore"), SearchService.LANGUAGE_XPATH,
                "/app:company_home");
        try {
            if (rs.length() == 0) {
                throw new AlfrescoRuntimeException("Didn't find Company Home");
            }
            nodeRef = rs.getNodeRef(0);
        } finally {
            rs.close();
        }
        return nodeRef;
    }

Questions: 

What are common causes for Node Reference retrieval failures specifically within a Kubernetes deployment of Alfresco? Could there be a configuration issue (Kubernetes or Alfresco) that's preventing correct XPath queries from working?

Troubleshooting Steps Taken:

Solr Reindex: I've fully reindexed the Solr search container.

Local Verification: Confirmed functionality in a local test environment.

Basic Searches: General searches seem to return files as expected.

1 Reply
afaust
Master

Re: Node Reference Retrieval Issues and XPath Issues in Alfresco 7.4 / Solr6 Kubernetes Deployment

For XPath lookups like /app:company_home there is the separate selectNodes-method in the SearchService API. Especially paths that should be guaranteed to exist / consistent should be resolved that way. The primary difference from the query method is that query always uses the index for XPath lookups, while selectNodes will use actual DB-based hierarchy traversals, unless you explicitly use full text search selectors in the XPath expression - and even then the evaluation will only use index-based sub-queries for those selectors individually.

The Lucene language should NOT be used at all anymore. Only FTS and CMIS are fully supported for index-based queries.

Other than these basic remarks, I have not run into any specific issues with index-based queries (even including paths like this) in k8s-based Alfresco deployments. Without additional information (like a screenshot from the Company Home node in Node Browser to check its actual primary path) or low-level inspection of the index state, it is hard to guess what might be the cause in your constellation.