Struggling with new index definitions is one of the most … annoying actions I do in AEM development. Because dropping indexing definitions with contentpackages directly into /oak:index is always a bit problematic (you need to have set the property “reindex=true” in your package, and what happens if you deploy the same package twice? Reindexing starts again, although nothing has changed), I greatly improved the EnsureOakIndex functionality in ACS AEM Commons a while back. I needed a reliable and automated way to add indexes to a huge number of AEM instances. It works quite well and is able to handle our indexing modification requirements.
Today I got the “complaint” from one of my colleagues, that they always need to restart the bundle to start this feature. Well, there’s a good reason for it. And I already had to explain a few times, so I thought it’s a good idea to post it here.
A production deployment is typically time-critical. That means it should complete within a certain amount of time (typically within 1hour or so). If you add an index to the system and the reindexing for this new index is enforced immediately at deployment time, it can have a massive impact on the deployment itself and the time needed for it.That’s mostly because of the impact of reindexing on the overall system performance; and depending on the index and the repository size this can take from seconds to days. That means that the immediate start of reindexing has a good chance to break your schedule. Therefor the indexes are not applied automatically. But you can always trigger it via JMX (search for “Ensure Oak Index”) to start the process of applying the changed index definitions.
But I understand, that this makes the handling of new indexes much more cumbersome for some people. If you interested in a (configurable) feature to apply new index definitions immediately, drop me a comment here or (better) raise a feature request on ACS AEM Commons Github page. Let’s see if we can make it happen 🙂
Things on a content management system 