Monitoring the progress of messages

solidDB^® provides a number of events that let you monitor the processes of propagating and refreshing data between a master and a replica. Two of those events are specifically for tracking how many bytes of a message have been sent or received so far. These events are useful primarily when sending very large messages, such as messages containing BLOBs, or when sending messages over very slow communication channels. If you are sending a BLOB, for example, you could use this to notify you after every 20K of data has been sent, and you could then update a screen display showing the amount of data that has been downloaded.

The two events are:
SYNC_MSGBYTES_SENT(
sender nodename	WVARCHAR,
receiver nodename	WVARCHAR,
message name	WVARCHAR,
cumulative_bytes_sent	INTEGER,
total_bytes	INTEGER);
SYNC_MSGBYTES_RECEIVED(
sender nodename	WVARCHAR,
receiver nodename	WVARCHAR,
message name	WVARCHAR,
cumulative_bytes_received	INTEGER,
total_bytes	INTEGER);

Both events essentially have the same parameters.

Both messages are posted 0 or more times during the process of forwarding a synchronization message between a master and a replica. SYNC_MSGBYTES_SENT events are posted in the transmitting node, and SYNC_MSGBYTES_RECEIVED events are posted in the receiving node.

The event lists the cumulative number of bytes sent/received so far as well as the total number of bytes to be sent/received inside the corresponding sync message. The user can monitor the progress of the sending/receiving process by catching these events and comparing the cumulative byte count sent so far to the total bytes in the message.

To control how frequently these messages are sent, you set the solid.ini configuration parameter

The value is specified in bytes, and must be greater than or equal to 0. Note that abbreviations, such as K for kilobytes, are not accepted in the value.

If the value is 0, then neither SYNC_MSGBYTES_SENT nor SYNC_MSGBYTES_RECEIVED events will be posted inside the corresponding node. The default value is 0 (i.e. no events are posted).

This parameter specifies the minimum number of bytes that must be sent before the first event is posted and in between each successive event. The server will post the first event after it has sent or received approximately the specified number of bytes, and will post another event each time it has sent or received approximately the specified number of additional bytes. For example, if RpcEventThresholdByteCount is set to 1000, then the server will post events at approximately the following times:

After 1000 bytes have been sent.

After 2000 bytes have been sent.

After 3000 bytes have been sent.

The RpcEventThresholdByteCount sets the MINIMUM number of bytes that must be transmitted before the first event and between each subsequent event. Events are not necessarily posted after exactly as many bytes as are specified in RpcEventThresholdByteCount. The server only checks the byte count and considers posting an event after it has completed the sending of each communication packet (not each byte). These packets are not necessarily the same size as RpcEventThresholdByteCount.

For example, suppose that RpcEventThresholdByteCount is 1000, and that you are sending 3500 bytes. Suppose also that each packet is 1500 bytes. Instead of getting events after exactly 1000, 2000, and 3000 bytes, you will get an event after the first packet (1500 bytes) and the second packet (3000 bytes).

As another example, suppose again that RpcEventThresholdByteCount is 1000, and that you are sending 3500 bytes. However, suppose this time that each packet is 600 bytes. Instead of getting events after exactly 1000, 2000, and 3000 bytes, you will get an event after the second packet (1200 bytes) and the 4th packet (2400 bytes) and the fifth packet (3000 bytes).

Note that the server does not post SYNC_MSGBYTES_SENT or SYNC_MSGBYTES_RECEIVED after the final packet has been sent (or received). Instead, after each complete message has been sent or received, the server will post another event, such as SYNC_MASTER_MESSAGE_RECEIVE_END.

If you plan to use SYNC_MSGBYTES_SENT and SYNC_MSGBYTES_RECEIVED, then we recommend that you also catch the starting and finishing events of the corresponding message. When you get an event that tells you that the specific synchronization message has been completely received, then you may want to unregister for that event, or at least stop executing a WAIT statement to wait for the next such event. Similarly, when you get an event saying that a new message is being forwarded (SYNC_MASTER_MESSAGE_RECEIVE_BEGIN) then you may want to start monitoring SYNC_MSGBYTES_RECEIVED.

Below is an outline of some of the message-related events that will occur.

▪There is only a single variable to control both the send and receive intervals. Within a node, the interval (byte count) for send and receive will be the same. Furthermore, "receive" events and "send" events will either both be on or both be off at the same time. You cannot turn on only one of them.

▪Since the sender and receiver are normally different nodes, they may have different values for RpcEventThresholdByteCount. In fact, one server can have such events turned off (RpcEventThresholdByteCount=0) while the other server has the events turned on.

▪For more information about waiting for synchronization events, see solidDB^® SQL Guide, especially the sections on the ADMIN EVENT and CREATE PROCEDURE commands.