Cluster Journal desription

• 1. Overview
• 2. Journal
• 3. Writing of Journal file
• 4. ID event generation
• 5. Master crash

1. Overview

In this chapter is presented the Cluster Journal.

all the configuration is performed in conf.xml, for more information see cluster configuration docu

2. Journal

Every node of the cluster maintains an index file (one row for every propagated event) named jei.jbx and n files (0.jbx, 1.jbx etc...) that store serialized events.

The format of index file is:

                [header]
                [item1 ]
                .........
                [itemN ]

                [header] := [LAST_ID_SAVED|MAX_ID_SAVED|ACTIVE_COUNTER]
                [item-i] := [ID | START_DATA_FILE | END_DATA_FILE | FILE_NAME | CONUTER ]
                

All data are integer :

• ID is the event identifier. This is unique in the cluster and is generated from the coordinator
• START_DATA_FILE is the position (in byte) in the store file where starts the event serialization
• END_DATA_FILE is the position (in byte) in the store file where ends the event serialization
• FILE_NAME integer name of the store file (the file names FILE_NAME.jbx)
• COUNTER is the last index file rotation whene the event was written

If an event must be retrieved, the id row in index file is read. FILE_NAME.jbx is opened (RandomAccessFile) and chunk from START_DATA_FILE to END_DATA_FILE is retrieved. This bytes are the object event serialized.

Store file has a max dimension of 10Mb. If this dimension is exceeded a new store file is created. In this version, old files is not removed.

3. Writing of Journal file

Journal is written on file every synchronization. Whene max dimenzion si reached, a rotation is performed (ID becomes 0 and counter is increased by 1). Whene a node start, it's index file is comparad to the one of the coordinator. If header is not equals, the node is declared disaligned and a realigment is forced. The coordinator sends all the event (from node:max_id_save - 20 to coordinator:max_id_saved) and node reexecute all the event not previously executed.

4. ID event generation

Coordinator generates unique ID and every node use this generation to retrieve event ID. Whene event is stored on journal , internal node id counter is increased so node is aligned.

5. Master crash

Whene master crash, nodes is unable to retrieve event ID. In this case node catch a SuspectedException and tries again to recover the id from the new coordinator.