4

I am facing strange issue with Sitecore publishing. When I am publishing any item from the CM server, it's not reflected in production immediately; while I can see this item on the CD server and preview it as well. It is taking time (in hours) to refresh on production. Sometime when I reset the IIS, it works, but it is not possible for all the time.

Publish:end and publish:end:remote are:

<event name="publish:end">
 <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
 <sites hint="list">
  <site>website</site> 
  </sites>
  </handler>
  <handler type="our_app.Site.Events.ClearXO, our_dll" method="OnPublishEnd" /> 
  </event>
 <event name="publish:end:remote">
 <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
 <sites hint="list">
  <site>website</site> 
  </sites>
  </handler>
  </event>

Could someone help me out with what is being missed there?

  • Does your handler clears the cache? – Hishaam Namooya Mar 27 '17 at 18:41
  • I am sure about CM server, cache is being cleared there. could you help to check it on CD servers. – Amit Sharma Mar 27 '17 at 18:47
  • Does your eventQueue enable? Is the value of processingInterval set 00:00:02 and finally, have you set the scalability setting? And what Sitecore version are you using? – Hishaam Namooya Mar 27 '17 at 19:00
  • Yes EventQueue is enable. and I am using Sitecore 6.5.0 (rev. 121009) – Amit Sharma Mar 27 '17 at 22:04
7

The reasons why the CD server is not clearing the cache is because the CD Server does not know what to do when receiving the events. So, you need to

Scalability Settings

The InstanceName is used (in this context) for comparison purposes, and for recording the instance that raised an event in the EventQueue, and the Publishing.PublishingInstance setting is used to ensure that all publishing operations are processed on a specific instance, e.g. if I have 3 CMs and set that to CM3 then CM3 will handle all publishing operations for the environment

On CM Servers:

<setting name="InstanceName">
   <patch:attribute name="value"></patch:attribute>
</setting>

<setting name="Publishing.PublishingInstance">
   <patch:attribute name="value">CM1</patch:attribute>
</setting>

On Publishing Server(1 of your CMs):

<setting name="InstanceName">
   <patch:attribute name="value">CM1</patch:attribute>
</setting>

<setting name="Publishing.PublishingInstance">
   <patch:attribute name="value"></patch:attribute>
</setting>

On CD Servers:

<setting name="InstanceName">
   <patch:attribute name="value"></patch:attribute>
</setting>

<setting name="Publishing.PublishingInstance">
   <patch:attribute name="value">CM1</patch:attribute>
</setting>

You also need to have eventQueue setting is enabled. In Sitecore v6.x to 7.2, it is found in the web.config and v7.5+ it is in the Sitecore.config

<setting name="EnableEventQueues" value="true">

and check if the ProcessingInterval of the EventQueue

<eventQueue>
  <!-- Time between checking the queue for newly queued events. If new events are found they will be raised. -->
  <processingInterval>00:00:02</processingInterval>
</eventQueue>

Core Database

Make sure that the events in the eventqueue table in core database of your CMs are also present in the eventqueue table of your CD. CM and the CDs should share the same core database, optionally through replication

Sites

Your sites should also be added to the publish:end and publish:end:remote events since by default, it contains only website. Note that, later on, when you have more sites you will require to update the config file. So, you can add a handler which reads your site definition and then clears the cache of the sites that you have.

Indexes

Make sure that there are no errors in your indexes. That is, Sitecore should be able to rebuild the indexes successfully else, the cache will not get cleared.

| improve this answer | |
  • The reason why ScalabilitySettings must be enabled isn't quite accurate. What you described is more the job of the eventQueue/processingInterval setting that you already described. Also, the InstanceName is used (in this context) for comparison purposes, and for recording the instance that raised an event in the EventQueue, and the Publishing.PublishingInstance setting is used to ensure that all publishing operations are processed on a specific instance, e.g. if I have 3 CMs and set that to CM3 then CM3 will handle all publishing operations for the environment. – Zachary Kniebel Mar 27 '17 at 20:27
  • Also, while the information that you provided for the core database is mostly accurate, replication of the core database is not necessary, in this context. Replication is a good practice for failover, but it actually isn't needed to make the EventQueues work in a scaled environment Replication can optionally be used for security purposes, preventing the CD from connecting to the CM's core database. As such, what I think you were trying to say is simply that the "CM and the CDs should share the same core database, optionally through replication". – Zachary Kniebel Mar 27 '17 at 20:36
  • Sounds good. It looks like when you were writing your post some of the sections got a little mixed up. Happens to the best of us. Comment and tag me when fixed and I'll upvote it ;) – Zachary Kniebel Mar 27 '17 at 20:42
  • You forgot about the changes to the core database section. Also, the detail that you previously provided for Scalability settings should be added to the description for the eventQueue/processingInterval – Zachary Kniebel Mar 27 '17 at 21:04
  • Can you update it accordingly? I will be removing previous comments – Hishaam Namooya Mar 27 '17 at 21:06
6

Sounds like the cache isn't getting cleared on publish. You'll want to add your site to the publish:end and publish:end:remote events.

<events>
      <event name="publish:end">
        <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
          <sites hint="list">
            <site>{site name}</site>
          </sites>
        </handler>
      </event><event name="publish:end:remote">
        <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
          <sites hint="list">
            <site>{site name}</site>
          </sites>
        </handler>
      </event>
    </events>
| improve this answer | |
  • HI @Patrick my config values for publish:end And publish:end:remote are: <event name="publish:end"> - <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache"> - <sites hint="list"> <site>website</site> </sites> </handler> <handler type="Our_APP.Site.Events.ClearXO, Our_DLL" method="OnPublishEnd" /> </event> - <event name="publish:end:remote"> - <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache"> - <sites hint="list"> <site>website</site> </sites> </handler> </event> – Amit Sharma Mar 27 '17 at 18:34
  • For <site>website</site> the website value should be your CM name. That tells the event handler to look for that and fire off on the CD. – RReilley Mar 27 '17 at 18:46
  • Looks like the publish end events are only wired up to your custom cache clearing. You'll want to add you site definition name to the sites list so that the needed Sitecore caches get cleared – Patrick Barron Mar 27 '17 at 18:51
  • +1 Great answer! @AmitSharma, it looks like you may also be using some sort of custom caching. If that is the case, try disabling your custom caching first and make sure that things work as expected. Once they do, re-enable your custom caching and troubleshoot more from there, if necessary. – Zachary Kniebel Mar 27 '17 at 20:47
0

Thanks Patirck and Hishaam for your kind help, I've found the cause of the reported behavior. There was difference in databases on CM and CD servers, when we made our connection string same on CD servers as CM server, it's been resolved.

Thanks, Amit

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.