If using Message Journaling with HA (Replicated or Shared), the EnableJournaling flag must be enabled at both the PRIMARY as well as the SECONDARY HA servers beforehand to avoid any message loss during failovers.
This is because, when the EnableJournaling flag is enabled through online/offline mode on a queue which is in the ACTIVE server, the configurations will not be replicated to the PASSIVE server. The journaling status for the queue in the PASSIVE server will remain false. Untill Journaling is enabled for the Queue in the 'ONCE PASSIVE NOW ACTIVE' server, the messages that are sent to this queue are not 'journaled' and message losses can be observed in the Journaling Queue. Therefore, the flag must be enabled, explicitly, prior to starting the servers to avoid message losses.
This can be done by making the following changes in the Configs.cfg file of both the HA servers. This is the block defining the destination parameters for the queue 'PRIMARYQUEUE'.
Points to Remember
- When the EnableJournaling flag is set to true on a destination, for example SAMPLE_DEST, a new Journaling destination is created in the FioranoMQ server. All incoming messages to the SAMPLE_DEST destination are replicated to the new journaling destination.
- The file storage 'type' for this new journaling destination is dependent on the configurable parameter 'DefaultStorageTypeForQueues/DefaultStorageTypeForTopics' which is present in Queue/Topic at the Subsystem level.
- Take the example of enabling Journaling on the queue SAMPLE_QUEUE which has the default File-based message storage. Reset the parameter from 'DefaultStorageTypeForQueues' to 'rdbms'. It may be necessary to enable the flag 'EnableRDBMS' and specify the RDBMS parameters in the profile. Please refer to Chapter 6 Configuring Message Store for more information.
Set the flag EnableJournaling on the SAMPLE_QUEUE by following the procedure mentioned in the previous sections. This will create the Journaling Destination JOURNAL_SAMPLE_QUEUE which has the RDBMS based message store.
Similarly, a File based storaged journaling queue can be created for a RDBMS based queue.
- By default, the EnableJournaling flag is set to 'false' for each destination in the FioranoMQ server and thus WILL NOT effect the performance of the MQ server when it is in the default mode. When the EnableJournaling flag is enabled, the performance of the MQ server is decreased significantly since this enables replicating all messages targeted on a destination to a different destination.
- Security ACLs are pre-defined for Journal Destinations based on the flag 'CreateDefaultACL' of Fiorano -> etc -> FMQConfigLoader. For more information on this parameter and on Security refer to Chapter 2 of FioranoMQ Reference Guide and Chapter 7 FioranoMQ Security. If this flag ] is set to 'true', the default ACL is set is not set to 'true', no ACL is defined for the Journaling destination. They behave normally like any other newly created destination in the Server.
- Persistent as well as Non-persistent messages can be journaled to a journaling destination.
- The EnableJournaling property is basically set at the destination level in the Server. Irrespective of the 'types' of subscribers created (Durable/Non-Durable) on particular topics, the incoming messages to a Topic are journaled to a different topic, if the 'EnableJournaling' flag is set to 'true'.
- Various FioranoMQ features such as Large Message support, Context Based Routing, XA etc work as expected in case of Journaling destinations.
- When EnableJournaling is enabled on a Queue, messages will be persisted, if necessary, for the Journaling destination as well. Therefore, these messages need to be consumed immediately or the disk space will decrease at twice the normal rate compared to when EnableJournaling is not enabled.
- This feature can be used when an administrator needs to Snoop all the messages that are incoming on a destination of any 'type'. This is different from the EnableSnooper function, which is supported on both Queues and Topics.The messages Snooped on all destinations will be replicated onto a single topic. By using this feature messages will be replicated to a destination of a similar 'type'.