[
https://issues.apache.org/jira/browse/AMQ-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557375#comment-13557375
]
Timothy Bish commented on AMQ-4212:
-----------------------------------
Fixing this is a bit tricky and would involve tracking the location of the
subscription commands in the log files for the StoredDestination and the
durable subs associated with each. The downside here is that you can start
retaining log files for only that one subscription command which isn't really
ideal.
Fixing this might lead down the path of needing periodic compaction or a means
at least of triggering one otherwise its quite hard to control how much wasted
spaced you'd have for the leftovers.
> Broker may be unable to recover durable topic subscription from the kahadb
> journal
> ----------------------------------------------------------------------------------
>
> Key: AMQ-4212
> URL: https://issues.apache.org/jira/browse/AMQ-4212
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.7.0
> Environment: kahadb and durable topic subscribers
> Reporter: Torsten Mielke
> Attachments: AMQ4212Test.java
>
>
> KahaDB is supposed to recover its index from the journal *completely*.
> Such recovery can be enforced by stopping the broker, deleting the db.data
> index file and restarting the broker.
> The recovery process may however not be able to recover inactive durable
> topic subscriptions.
> This is because the kahadb cleanup task will not consider any active
> subscription entries in the journal files when marking journal files for
> deletion.
> E.g. If a durable sub info was written to e.g. the journal file db-1.log but
> kahadb has already rolled over to writing to db-2.log, the cleanup task may
> delete db1.log (in case all msgs in db1.log got acked). The durable sub
> however is still alive.
> When stopping the broker this durable sub info is still present in the index
> file and will be restored at broker restart.
> If however the index file gets deleted in order to enforce a recovery of the
> index from the journal, then the broker has lost the information about this
> durable sub.
> The broker is therefore not able to recover its state fully from the journal
> files.
> If the durable subscriber remains inactive (i.e. does not reconnect to broker
> immediately after broker restart), it may miss messages as the broker has no
> knowledge of this durable sub.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
