Adobe Core Bundle (cq-dam-cfm-graphql) Not Starting After Rolling Restart

[Jade_WensylFa]

Hello, I'm doing investigation regarding the state of the bundles. 

When we performed rolling restart in publishers. We noticed 1 bundle were not proceeded to starting state. But this only happen in rare cases as we are doing a rolling restart multiple times and that bundle was properly start automatically by the AEM with no problem.

Checking the Bundle Event written in error.log. I noticed the pattern that all bundle after stopped it will go to resolved state and start again. This is the expected case.

Example 1:

Example 2:

However, one bundle was not activated. Specifically, cq-dam-cfm-graphql was stopped and tagged with [FelixStartLevel]. After that, it transitioned to the Resolved state, but this time the tag changed to [OsgiInstallerImpl] instead of [FelixStartLevel]. Please disregard the last two lines in the log, as I manually triggered the bundle to start.

Here are the questions that got me stuck for a while:

1. Is there any known issue or limitation with the cq-dam-cfm-graphql bundle in the current AEM version?

2. What does the [FelixStartLevel] tag usually indicate during bundle startup?
And what does the OsgiInstallerImpl tag represent? Why would it appear instead of FelixStartLevel in this case?

3. If I try to replicate this issue locally, what conditions need to be met?
I'm thinking I might not be able to reproduce it since the bundle usually starts automatically when AEM handles the restart.

[Jade_WensylFa]

By the way, addition to my initial investigation I noticed that it also applies to all publishers not just with one publisher. This seems weird. 

[EstebanBustamante]

Hi,

Could you let me know which AEM version you're using? From your description, it sounds like it might be a race condition — possibly a required dependency for the bundle you mentioned isn't starting consistently, which could be causing the issue you're seeing.

I’d recommend starting a fresh local instance using the same AEM version (publisher). First, test it without your custom codebase, and then try with your codebase to see if you can reproduce the issue.

Hope this helps

[Jade_WensylFa]

Hi @EstebanBustamante ,

We are currently using Adobe Experience Manager (version 6.5.20.0), as confirmed via /system/console/productinfo.

By the way, I tried your recommendation to run a newer AEM instance in my local instance with the same service package, but I couldn't reproduce the issue whether using our custom codebase or not.