While Kafkorama is designed for real-time messaging, some messages are retained in memory for a configurable period of time, as described below.
For each subject X
, every node in a Kafkorama cluster maintains a snapshot message — the most recent message
received with the retained
property set to true
. This applies to both clustering modes: Standard Message Delivery
and Guaranteed Message Delivery.
The table below illustrates how the snapshot message for the subject /Stocks/NYSE/IBM
evolves as new messages are received:
Time | Received Message | Snapshot Message |
---|---|---|
10:12 (first message) | subject=/Stocks/NYSE/IBM content=140 retained=false |
No snapshot available for /Stocks/NYSE/IBM at this time |
10:13 | subject=/Stocks/NYSE/IBM content=150 retained=false |
No snapshot available for /Stocks/NYSE/IBM at this time |
10:15 | subject=/Stocks/NYSE/IBM content=141 retained=true |
subject=/Stocks/NYSE/IBM content=141 retained=true |
10:25 | subject=/Stocks/NYSE/IBM content=144 retained=false |
subject=/Stocks/NYSE/IBM content=141 retained=true |
10:40 | subject=/Stocks/NYSE/IBM content=142 retained=true |
subject=/Stocks/NYSE/IBM content=142 retained=true |
When a client connects or reconnects to a node in the Kafkorama cluster and subscribes to a subject, that node first sends the current snapshot message (if available). Subsequently, the client receives any new real-time messages for that subject as soon as they are published, including messages originating from Kafka.
SnapshotExpireTime
parameter. This is especially useful when new subjects are
continuously added but not updated afterward — without a time limit, unused snapshots could accumulate and lead to
memory issues.
For clusters using Guaranteed Message Delivery, each node in the cluster maintains a history of recent messages for
each subject. If a client experiences a failure and reconnects, it automatically retrieves missed messages from this
history. These recovered messages are marked with the recovered
message type (see the Messages section).
Additionally, the client libraries provide a method to request a number of historical messages before receiving real-time updates:
void subscribeWithHistory(
List<String> subjects,
int numberOfHistoricalMessages
)
If the REST Client Interface is enabled, you can retrieve a snapshot message for a subject via a HTTP Request as shown here.
CacheExpireTime
parameter, and
limit the number of stored messages per subject using the parameter MaxCachedMessagesPerSubject
.