Few custom component attributes are missing in the page model json at publisher, leads to bad cache | Community
Skip to main content
V
vs5
February 16, 2025

Few custom component attributes are missing in the page model json at publisher, leads to bad cache

  • February 16, 2025
  • 5 replies
  • 939 views

Hello Everyone, 

 

We are facing an issue as "Few custom component attributes are missing in the page model json at publisher whenever page published. Issue is getting resolved after do a manual cache clear again.

Author model page json looks fine with all the component attributes.  

 

We are using the modelFactory.getModelFromWrappedRequest to get the component json of an experience fragment. 

Appreciate any help on this.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

5 replies

ayush-anand
ayush-anand
Level 4
February 16, 2025

Hi @vs5 ,


The issue is likely due to caching, as it gets resolved when manually clearing the cache. The dispatcher might be serving an outdated .model.json. Please ensure dispatcher cache invalidation for /model.json after publishing.

Regards,

Ayush

    V
    vs5Author
    February 17, 2025

    Hi Ayush,

     

    Yes, after every page publish, dispatcher will be invalidated automatically. Its already in place. We are trying to figure out the possible reasons for missing the component attributes in the page model json once in awhile.

    Its not consistently happening. And when the issue happen, only few page requests are served from the bad cache at dispatcher, we see both good and bad caches at dispatcher (in multiple instances).

     

    Regards,

    Vinay

     

    A
    Anil_Chennapragada
    Level 4
    February 18, 2025

    hi @vs5 ,

    Hope you have already figured the solution for this. Few thoughts if not

     

    Not sure of the content size in your project use- case. These kind of issues happen mainly when there is a delay due to dispatcher flush configurations, replication queues , network issues or the As in your case its happening intermittently, dispatcher flush rules might not be the issue. Please try following options in case you encounter this issue again

    • Verify replication queues
    • Verify if the data is reflecting in direct publishers
    • Monitor the health of the specific publish instance where you are noticing this issue
    • If possible, see if you can optimize the flush rules (TTL based etc.) 

     

    Thanks,

    Anil

      V
      vs5Author
      February 25, 2025

      Thanks very much Anil,

       

      Couple of your suggestions makes sense, but I can check this only when the issue arise in production, its not happening in any of the lower environments. 

      Can we check the response of specific publisher/dispatcher instance or node?

       

      Thanks

      Vinay 

      tushaar_srivastava
      tushaar_srivastava
      Level 6
      February 19, 2025

      Hi @vs5 

      I came  across similar issue during a POC while working on the caching behavior of Experience Fragments in a headless AEM setup [version was AEM6.5.21~]. The weird and strange part was, just like in your case, it didn’t happen consistently—sometimes the .model.json was complete, and sometimes certain attributes were missing, even though cache invalidation was working.

      duringmy POC across AEM publish, dispatcher, and model serialization, here’s what I found and how we fixed it:

      Possible Fixes
      1. Race Condition in Cache Invalidation Acrosss Dispatchers
      Since you mentioned some requests serve bad cache while others serve the correct one, it sounds like a timing issue between publish and dispatcher cache invalidation. Some dispatcher nodes might be serving stale cache while others have already updated.
      solution : Try ading a short delay (1-2 sec) before cache invalidation to ensure the latest .model.json is fully available before dispatchers purge old cache.

      2. Incomplete Model JSON Serialization in Publish Instance
      Soluton : If the attributes are always present on Author but sometimes missing on Publish, the issue could be with how AEM serializes the model in a wrapped request. If modelFactory.getModelFromWrappedRequest() is used, it may not fully resolve nested models when caching is involved.

      @Inject @Named("customAttribute") @JsonProperty("customAttribute") private String customAttribute;

      This forces attributes to be always included, even when wrapped via modelFactory

      3. Stale Dispatcher Cache Serving Partial JSON
      Even though you already have cache invalidation in place, I’d suggest double-checking if all dispatchers purge at the same time.
      Try manually purging the cached .model.json across all dispatchers and see if that eliminates the issue permanently. You can also enforce this in dispatcher.any:

      /0001 { /glob "*.model.json" /type "allow" }

      ensures any request for model.json forces invalidation and prevents inconsistencies.

       

       

        V
        vs5Author
        February 25, 2025

        Thank you Tushaar for the suggestions,

         

        As modelFactory.getModelFromWrappedRequest() is being used in my logic, I need to try to @586265 for the variables.

        Also will try to see possibility to check around other suggestions too.

        Will update the post with the out come.  

         

        Thanks

        Vinay

         

         

        tushaar_srivastava
        tushaar_srivastava
        Level 6
        February 19, 2025

        or maybe be you can change approach to sling job

        kautuk_sahni
        Community Manager
        kautuk_sahniCommunity Manager
        Community Manager
        July 14, 2025

        @vs5 Just checking in — were you able to resolve your issue?
        We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!

        Kautuk Sahni
        Terms & ConditionsAccessibility statement

        Loading footer...