xmlBlaster - Requirement cluster.dirtyRead

REQUIREMENT

cluster.dirtyRead

Type NEW

Priority HIGH

Status CLOSED

Topic A cluster slave node can directly cache published messages

Des
cription
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).

Example
XML

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

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

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

Topic	A cluster slave node can directly cache published messages
Des cription	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).
Example XML
Configure	The dirty read attribute has to be set at all stratum levels to be active, here `heron` declares it (he is the master): cluster.node[heron.mycomp.com]=\ <clusternode id='heron.mycomp.com'>\ <master type='DomainToMaster' dirtyRead='true'>\ <key queryType='DOMAIN' domain='RUGBY_NEWS'/>\ </master>\ </clusternode> 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