Configure remote cache invalidation

Use Apache Kafka and Apache ZooKeeper, we can run cache invalidation from the WebSphere Commerce Transaction server, or remotely from a Liberty server. We can enable and customize this feature by editing WebSphere Commerce configuration files.


Before beginning

WebSphere Commerce Version 9 uses Apache Kafka and Apache ZooKeeper to seamlessly synchronize data across multiple servers. The following procedure assumes that you have working installations of both products on your network. Important: Install and run Kafka and ZooKeeper as isolated servers in dedicated Docker containers. Neither application is bundled with WebSphere Commerce.


Task info

Complete the following three procedures to enable remote cache invalidation:


Procedure

Configure the Transaction server

  1. Open WebSphere Commerce Developer and switch to the Enterprise Explorer view.

  2. Go to the following directory. workspace_dir\WC\xml\config\com.ibm.commerce.foundation

  3. Edit the Transaction server custom configuration file wc-component.xml. If the file does not exist, create it.

  4. Locate the wc.store.remote.kafka parameter of the RemoteStoreConfiguration configuration grouping. Add the addresses of the Apache Kafka broker clusters, as a comma-separated string, to the value attribute. Set the port numbers according to your local environment. For example: 

      <_config:configgrouping name="RemoteStoreConfiguration">
    ...
    <!-- value to kafka servers connection string -->
    <_config:property name="wc.store.remote.kafka" value="kafka-broker1:9092,kafka-broker2:9092,kafka-broker3:9092"/>
    ...
</_config:configgrouping>

  5. Locate the wc.store.remote.kafka.topicPrefix parameter in the same configuration grouping. Add the topic prefix for cache invalidation. This string contains the same value as the prefix configured in the remote store server. The value must be same across Transaction servers. 

      <!-- value to kafka servers topic prefix -->
    <_config:property name="wc.store.remote.kafka.topicPrefix" value="sampleprefix"/>

  6. Locate the wc.remote.zookeeper parameter of the TransactionKafkaConfiguration configuration grouping. Add the addresses of the Apache ZooKeeper servers, as a comma-separated string, to the value attribute. Set the port numbers according to your local environment. For example: 

      <_config:configgrouping name="TransactionKafkaConfiguration">
    ...
    <_config:property name="wc.remote.zookeeper" value="zookeeper1:2181,zookeeper2:2181,zookeeper3:2181/kafka"/>
    ...
</_config:configgrouping>

  7. Save and close the custom configuration file.

Configure the Store server

  1. Go to the following directory. workspace_dir\Liberty\servers\crsServer\configDropins\overrides

  2. Edit the custom configuration file jndi.xml. If the file does not exist, create it.

  3. Add the configuration string for the ZooKeeper servers to the jndiName attribute of the jndiEntry element. The value is the same as the ZooKeeper configuration string in the Transaction server. 

      <jndiEntry jndiName="com.ibm.commerce.foundation.server.services.zookeeper.hostnameport" value=""/>

  4. Add the topic prefix string. This value is the same as the topic prefix string in the Transaction server. 

      <jndiEntry jndiName="com.ibm.commerce.foundation.server.services.cacheinvalidation.topicprefix" value=" "/>

  5. Save and close the custom configuration file.

Enable cache invalidation for messages that are sent from the Transaction server

  1. Go to the following directory. workspace_dir\WC\xml\config

  2. Edit the custom configuration file wc-server.xml. If the file does not exist, create it.

  3. Set the jobinterval parameter to an integer value greater than zero. Ensure that the localJVMOnly parameter is set to false.

    Where:

      invalidationJobInterval
      The number of seconds to wait before polling the CACHEIVL table for new content. If a high polling rate is causing performance issues, we can increase the value to several minutes (for instance by setting the value to 300, equal to 5 minutes). Note that this parameter only affects how often the Transaction server checks the CACHEIVL table, not how often caching itself occurs.

  4. Save and close the custom configuration file.

  5. Deploy our changes to the WebSphere Commerce runtime environment.

Example

We can examine the contents of your messages by using Kafdrop, or use kafka-manager to manage the topic and brokers. Messages have the following format, depending on the transaction.Transaction server to Transaction server messages have the following format:

Transaction-to-Store messages have a similar format:


What to do next

To improve performance and optimize data for analysis, we can enable, disable and customize individual cache settings. The following Transaction and Store server DistributedMaps are relevant to Kafka.

For information about customizing the DistributedMaps, see Additional WebSphere Commerce data cache configuration.