XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority HIGH
Topic A cluster slave node can directly cache published messages

Usually if you publish a message to a cluster slave node, the message is directly forwarded and routed to the master node of this message type.

If clients connected to frodo (a slave node) subscribe to messages frodo subscribes it from heron, as heron is the master. Only messages coming from the master are approved. The slaves receives the update and delivers it to the client:

It is possible to suppress the update (2.1.1) as the slave can just as well dirty read the published message at step (2):

The main reason for this requirement is to minimize net traffic on connections between cluster nodes with limited band width.
For example if you send 1200 radar messages / sec over a 2MBit net the band width is almost exhausted. With dirty reads you can allow the cluster slave to cache those messages directly without approving from the master node and updating back again (assuming you have local subscribers at the slave node).


The dirty read attribute has to be set at all stratum levels to be active, here heron declares it (he is the master):

   <clusternode id='heron.mycomp.com'>\
      <master type='DomainToMaster' dirtyRead='true'>\
         <key queryType='DOMAIN' domain='RUGBY_NEWS'/>\

and frodo as a slave will dirty read messages of the domain RUGBY_NEWS.

See xmlBlaster/demo/javaclients/cluster for more examples.

NOTE: Configuration parameters are specified on command line (-someValue 17) or in the xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
Columns named Impl tells you if the feature is implemented.
Columns named Hot tells you if the configuration is changeable in hot operation.

See REQ cluster
See TEST org.xmlBlaster.test.cluster.DirtyReadTest

This page is generated from the requirement XML file xmlBlaster/doc/requirements/cluster.dirtyRead.xml

Back to overview