journald: Properly handle journal EOF

The logic of handling EOF is incompatible between journald API and
CIM_MessageLog model we use. The CIM_MessageLog.GetRecord() method
allows stepping to the next record after data retrieval but there's
no specific return code for the EOF case. And returning failure code
makes the client application think the whole data retrieval has failed
and thus throwing away the last record.

To work around this case, a new flag has been introduced to the
IterationIdentifier string, which is considered opaque to the client.
That way we return success from the GetRecord() method call and putting
a flag to the IterationIdentifier string so that any successive GetRecord()
method call properly fails without any data loss. Care is taken of the
case when a new message is logged between the GetRecord() calls.

This commit also adds the CIM_MessageLog.PositionToLastRecord() method
for convenient access to the end of the journal.

0 files changed, 0 insertions, 0 deletions