2

Here is the setup I have.

Web Server A

  • Proof site
  • Staging site
  • Live site
  • Proof uploader (deployer)
  • Staging uploader (deployer)
  • Live uploader (deployer)

Web Server B

  • Proof site
  • Staging site
  • Live site
  • Proof uploader (deployer)
  • Staging uploader (deployer)
  • Live uploader (deployer)

Both web servers have the cache channel service running on it. All sites have caching enabled in cd_storage_conf_xml (deployer and site).

Here is a sample of what the config looks like

<ObjectCache Enabled="true">
        <!--Optional:-->
        <Policy Type="LRU" Class="com.tridion.cache.LRUPolicy">
            <!--
                The maximum size of memory used by the cache. The string must consist a number 
                followed by units: "k" or "kb" for kilobytes; "m" or "mb" for megabytes (case insensitive)
            -->
            <Param Name="MemSize" Value="128mb"/>
        </Policy>

        <!--Optional:-->
        <!-- The Features element specifies classes that add additional functionality to the cache. -->
        <Features>
            <Feature Type="DependencyTracker" Class="com.tridion.cache.DependencyTracker"/>
        </Features>
        <!--Optional:-->            
        <!--
                The optional RemoteSynchronization element specifies a remote Cache Channel Service.
                The remote Cache Channel Service is used to send messages between caches that are running
                on separate virtual machines. (For example, if the Broker and the Deployer run on separate
                virtual machines.)
                The Cache Channel Service must be running and listening on the configured host and port for
                remote synchronization to function.
                If this element is omitted, the cache does not use any inter-virtual machine cache communication.
                You must use the RemoteSynchronization element in conjunction with the Cache Channel service in
                order for objects to be updated or removed from the Broker's object cache when they are published
                or unpublished using the Deployer.
        -->
        <!-- RMI CacheChannel Connector example-->

        <RemoteSynchronization Queuesize="128" ServiceMonitorInterval="10000" FlushCacheDuringDisconnectInterval="20000">
            <Connector Class="com.tridion.cache.RMICacheChannelConnector" Host="127.0.0.1" Port="1099" />
        </RemoteSynchronization>

<ItemTypes defaultStorageId="defaultdb" cached="true">
 <Item typeMapping="Page" cached="true" storageId="defaultdb"/>
    <Item typeMapping="Binary" cached="true" storageId="defaultdb"/>

Here is the issue When I publish a content item to all 3 sites (staging, proof, live) both server node A and node B for staging get the updated content.

For live and proof node B never resets its cache.

Why are nodes B on live and proof not resetting their cache???

Update:

Each sites (staging, proof, live) have their own broker database but each web server (A and B) point to the same broker DB. Each server does have a deployer running for each site.

Improve this question
1
  • Do Webserver A and B each have their own Broker database?
    – Bart Koopman
    Commented Mar 5, 2015 at 9:28

2 Answers 2

Reset to default
3

I would centralized CCS on one server. Instead of having CCS running on server A and B, have it configured to run on server A and have the webapp connect to server B. In the cd_storage_conf.xml on webapp B configure the remote synchronization to ServerA

Improve this answer
4
  • Thanks trying that but given one of the sites works fine under this local CCS config I have been assuming that is not really the issue. Why would it work locally for one webapp but not the others?
    – ToddB
    Commented Mar 5, 2015 at 1:31
  • 2
    Considering each webserver has their own Deployers, if they also have their own (separate) Broker DB, then you should NOT have a single CCS, but each should have its own CCS indeed. It would only make sense to have a single CCS, if there was a single Deployer and a single Broker DB (multiple Deployers on a single Broker DB is not supported, since that would cause issues).
    – Bart Koopman
    Commented Mar 5, 2015 at 9:30
  • I updated the question to clarify this. Each site has its own Broker but each server for that site points to the same Broker. But we do have two deployers running.
    – ToddB
    Commented Mar 5, 2015 at 14:12
  • Makes me sad to mark this as the answer but as @nuno-linhares noted below it is what we are left with and we have to have a SPOF. Thanks guys!
    – ToddB
    Commented Mar 5, 2015 at 15:53
2

This article is probably the best starting point for you to understand the object cache and cache channel service relationship.

In a nutshell, all your web application servers are Cache Channel Service clients that listen for updates. Your Deployer is the one piece providing information about which items should be flushed from cache.

If all your app servers connect to different Cache Channel Services then they can't possibly get the invalidation messages. Instead, ALL of your servers (including the deployer) for a given environment ("Live" or "Staging") should be connected to the same Cache Channel Service, or you will see weird results - as you are seeing.

Also, Tridion will do funny stuff if it can't connect to a Cache Channel Service, like stop trusting the cache - so it is possible that the server where you're seeing updated content is simply bypassing the cache altogether rather than using it.

Improve this answer
7
  • Thank Nuno. I did read through that yesterday. My thought was that the CCS was looking to the Broker DB to see if cache needs to expire. So CCS sends notification to Broker DB M. The CCS service on server A reads Broker M to see it needs to expire cache. The CCS service on Server B does read from the same broker DB and also sees it needs to expire its cache. You are saying that is not how it works and we need only one CCS and one deployer for the web farm. My concern is that this forces Tridion into a single point of failure Architecture (a single deployer and a single CCS).
    – ToddB
    Commented Mar 5, 2015 at 14:19
  • 1
    Yes. We don't use the database for cache invalidation because you can run Tridion without a database... Agreed on SPOF, and that's something we're actively looking into. You can "work around" the SPOF by using JMS instead of RMI. See blog.trivident.com/category/jms-2
    – Nuno Linhares ♦
    Commented Mar 5, 2015 at 14:53
  • Thanks for the help Nuno. It is disappointing that create a SPOF is the answer here and right now the only way to make it (IMHO) enterprise class is to not use Tridion's caching approach but instead use a work around. We currently have not gotten our queue infrastructure in place so we are forced to have a SPOF.
    – ToddB
    Commented Mar 5, 2015 at 15:50
  • Huh... JMS is not a workaround, is a fully supported messaging channel with Tridion Cache. It's an alternative. (poor choice of words from me initially)
    – Nuno Linhares ♦
    Commented Mar 5, 2015 at 16:22
  • 1
    @ Nuno, Tridion does not play well with tools like Tibco, Windows Service Bus (both support JMS specifications) as we've tried to use both and did not get it to work with any of them. We have tried connecting with Tibco and we ran into issues of Tridion cache jar implementation always picking up the current thread user account (domain based) for authentication to send messages (while JMS supports thread based as well as a different username and password for authentication for messages). With windows SBus, which is a file based implementation (it uses properties file to specify connection and o
    – Vipin Kothari
    Commented Mar 5, 2015 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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