Global Cache in Message broker
An in-memory cache where some details can be stored and deleted later.By this way information can be shared between processes(Brokers,EGs).
Egs:
Correlation information
Avoiding the frequent backend interactions by storing some frequently queried data
Scenarios
This is built based upon Websphere Xtreme scale technology.
WebSphere® eXtreme Scale is an elastic, scalable, in-memory data grid. The data grid dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers. WebSphere eXtreme Scale performs massive volumes of transaction processing with high efficiency and linear scalability. With WebSphere eXtreme Scale, you can also get qualities of service such as transactional integrity, high availability, and predictable response times.
The WebSphere Message Broker global cache is implemented using embedded WebSphere eXtreme Scale (WebSphere XS) technology. By hosting WebSphere XS components, the JVMs embedded within WebSphere Message Broker execution groups can collaborate to provide a cache.
There are three components involved in Global cache:-
1)Catalog server-To control
2)Container server-To hold cache data
3)Map-To map key value pair
Default Global cache is only one Broker scoped.First EG which startsup will act as both Catalogue Server and Container Server.The next 3 Egs will act as Container Servers.And further Egs will connect as clients to the cache hosted in Egs 1-4.
Note : If we set policy as none,then we can individually tune the Execution groups cache components instead of letting them to start dynamically.
How Catalog server and Container server are connected?
The execution group started first will act as both catalog server and container server.And 3 execution groups can act as container server.All of these 4 EGs will have a port.
The remaining EGs will connect to these container servers as clients.They will not have any ports.
When you restart the broker, the execution groups may start in a different order, in which case different execution groups might perform Roles1, 2, 3, and 4.
When you use the default topology, execution group properties are read only; an error is issued if you try to change them. You can switch off the default topology by selecting a broker cache policy of none, and set properties explicitly for each execution group. For example, you might want to specify particular execution groups to host the catalog and container servers so that you can tune broker performance.
mqsicacheadmin
Since resource statistics and activity traces can provide only an isolated view from each execution group, there is also the mqsicacheadmin command, which provides information about the entire global cache.
What happens if I shut down an execution group that hosts a catalog server?
If it is the only catalog server, then your cache is gone. However, if you have configured your cache to have more than one catalog server, and they have successfully handshaked on startup, then the remaining catalog server (or servers) will continue to run the cache without interruption. When you restart the execution group, the catalog server will rejoin the topology.
Interacting with the global cache or external grid
You can interact with the global cache or external grid by using a JavaCompute node. The node can put data into a map, retrieve data, and create a map if one does not exist.
What is cache policy file?
This cache policy file helps us to shape the cache topology across one or more than one brokers.
Sample Policy files can obtained in :
C:\Program Files\IBM\MQSI\9.0.0.1\sample\globalcache
As soon as we restarted the Broker(Named as Integration Node in IIB),the first EG(Named as Integration Server in IIB) came up with container server and Catalog server,
Second EG came as Container server:
More about Policy files:
In the below picture,the 4 types of policy files are shown.
If Default –then Broker can chooses default topology. Default Global cache is only one Broker scoped.First EG which startsup will act as both Catalogue Server and Container Server.The next 3 Egs will act as Container Servers.And further Egs will connect as clients to the cache hosted in Egs 1-4.
If None – We need to explicitly define the Egs for Catalog and Container servers
If Disabled – Then Global cache is disabled;This is the Default broker configuration
In last option –we can specify policy xml file to structure the cache topology for more than one brokers
*How to interact with Global cache?
If you set Globalcache to none,then you need to set the EGs Globalcache configurations explicitly,
1) stop the broker and execute the below command :
mqsichangebroker MB8BROKER -b none
2) start the broker
** mqsichangeproperties MB8BROKER -b cachemanager -o CacheManager -n policy,portRange,listenerHost -v none,2800-2819,localhost
**mqsichangeproperties MB8BROKER -e MB8EG -o ComIbmCacheManager -n enableCatalogService -v true
**mqsichangeproperties MB8BROKER -e MB8EG -o ComIbmCacheManager -n enableContainerService -v true
MQ Explorer Global Cache monitoring
In MQExplorer resourcemanager-->Global Cahce Activity log
You will be able to see the container server and catalog servers are up
and Global cache connected to cache name WMB.
1)Execute the below code in a flow where you are creating the map and updating the map with key-value pair,
importcom.ibm.broker.javacompute.MbJavaComputeNode;
import com.ibm.broker.plugin.MbException;
import com.ibm.broker.plugin.MbGlobalMap;
import com.ibm.broker.plugin.MbMessage;
import com.ibm.broker.plugin.MbMessageAssembly;
import com.ibm.broker.plugin.MbOutputTerminal;
import com.ibm.broker.plugin.MbUserException;
public class GC_Sample_JavaCompute extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly inAssembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
//MbOutputTerminal alt = getOutputTerminal("alternate");
String Varkey="MyKey";
String Varval="Radha";
MbGlobalMap MyglobalMap = MbGlobalMap.getGlobalMap("MyMap");
MyglobalMap.put(Varkey, Varval);
MbMessage inMessage = inAssembly.getMessage();
MbMessageAssembly outAssembly = null;
try {
// create new message as a copy of the input
MbMessage outMessage = new MbMessage(inMessage);
outAssembly = newMbMessageAssembly(inAssembly, outMessage);
// ----------------------------------------------------------
// Add user code below
// End of user code
// ----------------------------------------------------------
} catch (MbException e) {
// Re-throw to allow Broker handling of MbException
throw e;
} catch (RuntimeException e) {
// Re-throw to allow Broker handling of RuntimeException
throw e;
} catch (Exception e) {
// Consider replacing Exception with type(s) thrown by user code
// Example handling ensures all exceptions are re-thrown to be handled in the flow
throw new MbUserException(this, "evaluate()", "", "", e.toString(),
null);
}
// The following should only be changed
// if not propagating message to the 'out' terminal
out.propagate(outAssembly);
}
}
When you enable the Resource statistics for this Execution Group,you can see that 1 map is used:-
Types of Global cache:
In 8.0.0.1 broker,Global cache was introduced and in this version WMB can interact with only Embedded Global cache.
In IIB,broker can also interact with External Websphere Extreme Scale grid.For this,we need to create Configurable service and provide the details of External Websphere Extreme Scale grid server.
In WMB 8,Multiinstance brokers cannot host Catalog and Container servers.
In IIB, Multiinstance brokers can host Container server.But not Catalog server still.