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

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

cjbautista

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.

afaust

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.