Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Externalizer Service Unbinding Configurations

Avatar

Level 3

Hello community,
I have been trying to troubleshoot a strange issue where the externalizer service configurations are being unbound - somewhat randomly.  This is occurring multiple times per day, and I haven't been able to attribute this issue to any particular event.  I am able to fix the issue by deleting and replicating the existing configuration from author to publish.  

Symptom

When this issue occurs the project specific configurations for the externalizer are unbound and all sites configured are not externalized correctly.  

Error Log Message

 

*ERROR* GET /content/page/path.html HTTP/1.1] com...core.rewriter.impl.LinkRewriterService Could not externalize link: /path.html - site: domain java.lang.IllegalArgumentException: Could not find configuration for domain 'domain' at com.day.cq.commons.impl.ExternalizerImpl.externalLink(ExternalizerImpl.java:308) [com.day.cq.cq-commons:5.11.18] at com.day.cq.commons.impl.ExternalizerImpl.externalLink(ExternalizerImpl.java:299) [com.day.cq.cq-commons:5.11.18] at com...core.rewriter.impl.LinkRewriterService.externalizeLink(LinkRewriterService.java:179)

 

This error is thrown because the configuration file for the service is not bound.

Related Log Messages

I have noted a few log messages that appear to be related.  I see these messages before the externalizer error is thrown. 

 

*INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.commons.impl.ExternalizerImpl)] com.adobe.granite.maintenance.core Service [com.adobe.granite.maintenance.impl.MaintenanceJobsManagerImpl,72724, [com.adobe.granite.maintenance.impl.MaintenanceJobsManager]] ServiceEvent UNREGISTERING
*INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.commons.impl.ExternalizerImpl)] com.day.cq.cq-commons Service [com.day.cq.commons.impl.CommonAdapterFactory,82648, [org.apache.sling.api.adapter.AdapterFactory]] ServiceEvent UNREGISTERING
*INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.commons.impl.ExternalizerImpl)] com.adobe.granite.maintenance.core Service [com.adobe.granite.maintenance.impl.TaskScheduler,474961, [org.apache.sling.discovery.TopologyEventListener, org.apache.sling.api.resource.observation.ResourceChangeListener, org.apache.sling.launchpad.api.StartupListener]] ServiceEvent UNREGISTERING

 

I can confirm that the scheduled maintenance jobs/tasks are not running when this issue identified, and I cannot recreate the issue by triggering the scheduled maintenance. 

Any insight or help you could provide on this issue would be greatly appreciated.

1 Accepted Solution

Avatar

Correct answer by
Level 3

It looks like this issue was caused by the ConfigurationAdmin service.  We were referencing the ConfigurationAdmin in a service and it appears to be the culprit.

@Reference private ConfigurationAdmin configurationAdmin;

 

View solution in original post

4 Replies

Avatar

Community Advisor

Hi @jarvislukow 

Could you please share the below details 

  • Is it happening only on Publish instance. 
  • How is the externalizer config included. Is it part of code base or directly in Felix console. 

Avatar

Level 3

Thanks for responding @Vijayalakshmi_S 

  • Yes it's only happening on publish
  • We are including the config as part of our code repo and build

Avatar

Community Advisor

Thanks for the inputs @jarvislukow 

Could you please check this events console of your publish instance -  http://localhost:4502/system/console/events

and check

  • how often the externalizer unregistering event is getting triggered
  • timeframe at which this is happening (you can cross check if any other activity is happening in the instance at the same time)

Does it happen in all the environment's publish instance or any specific environment (Dev/QA/Stage/Prod)

 

Avatar

Correct answer by
Level 3

It looks like this issue was caused by the ConfigurationAdmin service.  We were referencing the ConfigurationAdmin in a service and it appears to be the culprit.

@Reference private ConfigurationAdmin configurationAdmin;