AEM 6.5.5 Not Indexing Problem *Fixed*

In the course of establishing a new multitenant website, we opted to re-use the search mechanism for both site1 and site2. However, following the deployment of our code to the cloud QA environment, a significant hurdle surfaced: site2’s search consistently failed to produce results. This revelation made us to invest considerable effort in a detailed debugging journey.

Follow this step-by-step guide below as we transparently outline each phase of our process to resolve this issue.

Navigating the challenges posed by the AEM 6.5.5 indexing problem, we’ve acquired invaluable insights that we believe will prove highly beneficial to the broader community. It’s crucial to emphasize that the focus of this article is specifically on the on-premises AEM 6.5.5 solution, distinct from the AEMaaCS solution.

Step 1: Identifying the Issue with the Query Performance Tool

Our initial step involved using the query performance tool provided by AEM 6.5.5: /libs/granite/operations/content/diagnosistools/queryPerformance.html. This tool allowed us to pinpoint the queries in use. As we focused on the search entry for site2, we discovered that the Lucene index was incorrectly utilizing the index intended for site1. This realization prompted us to proceed to the next step.

Step 2: Updating Lucene Index Properties

In the second step, we accessed crx/de and located the Lucene index entry under /oak:index/*. After finding the node, we updated the node properties, setting resync = false. Monitoring the indexing logs, we confirmed a successful reindex. Despite obtaining the exact query for site2’s request, using the explain query tool revealed that the results were not as expected. Undeterred, we proceeded to the next step.

Step 3: Deleting and Remaking %_TARGET_FOLDER_%

With the issue persisting, we decided to take more decisive action in the third step. We shut down AEM, deleted ./crx-quickstart/repository/index/%_TARGET_FOLDER_%, and restarted the environment. After waiting for 5-10 minutes, the logs indicated that the %_TARGET_FOLDER_% had been remade. Unfortunately, using the explain query tool still showed unexpected results, prompting us to move on to the next approach.

Step 4: Complete Index Folder Deletion

For the fourth step, we took a more extensive approach by shutting down AEM and deleting the entire index folder: ./crx-quickstart/repository/index/*. After restarting and patiently waiting for 10-30 minutes, the logs confirmed the successful recreation of the index folder. However, the query results were still not meeting our expectations.

Step 5: Unconventional Solution

By the fifth step, conventional options exhausted, we attempted an unconventional approach. Authorizing into crx/de, we forcefully deleted both site1 and site2’s oak:index rules. Subsequently, we reinstalled the rules for both sites. The result? A surprising success, with site2’s search now functioning as expected.

Conclusion

Navigating the intricacies of AEM 6.5.5’s indexing system can be challenging. However, with a systematic approach and a willingness to explore unconventional solutions, it’s possible to overcome seemingly insurmountable issues. By sharing our step-by-step journey, we hope this article proves valuable to others facing similar challenges in the realm of AEM development.

AEM 6.5.5 Not Indexing Problem Fixed