Resolution:
When message confirmation activity for the subscriber is used after some others activities in case of exception of the activity (e.g. JDBC Call timeout) the confirmation will not be sent back. In such situation this particular message will not be confirmed, hence will not be removed from the ledger file.

From now on all new messages will not be confirmed either. Although messages can be received properly and the confirmation is sent from the subscriber application to the publisher they will not be considered as confirmed and removed from the ledger file till the confirmation of the first unconfirmed message.

RVCM sender must have all messages sequentially confirmed before deleting them from ledger file.

RVCM messages should be confirmed as soon as they arrive to the subscriber.

Using explicit confirmation of the messages to achieve transactional behaviour is not the proper design of the application. Unconfirmed messages will not be republished and the ledger file will grow till the restart of the RVCM transport.