[
https://issues.apache.org/jira/browse/AMQ-7082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656995#comment-16656995
]
Alan Protasio edited comment on AMQ-7082 at 10/19/18 4:15 PM:
--------------------------------------------------------------
So, we can lock only if the recoveredFreeList is not empty AND freeList is
empty then ... no? This is a good trade off... we only have this hit during the
recovery AND we need more free pages.... Imagine that probably allocate new
pages will take more time than this sync...
Would be amazing to have this free pages as soon we know about them... -Maybe
with this we AMQ-7080 stop making sense at all...- (AMQ-7080 can still have
the potential to avoid lots of read - On a NFS we can have a limited throughout
- mb/s - So maybe this still good)
was (Author: alanprot):
So, we can lock only if the recoveredFreeList is not empty AND freeList is
empty then ... no? This is a good trade off... we only have this hit during the
recovery AND we need more free pages.... Imagine that probably allocate new
pages will take more time than this sync...
Would be amazing to have this free pages as soon we know about them... Maybe
with this we AMQ-7080 stop making sense at all...
> KahaDB index, recover free pages in parallel with start
> -------------------------------------------------------
>
> Key: AMQ-7082
> URL: https://issues.apache.org/jira/browse/AMQ-7082
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
> Affects Versions: 5.15.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 5.16.0
>
>
> AMQ-6590 fixes free page loss through recovery. The recover process can be
> timely, which prevents fast failover, doing recovery on shutdown is
> preferable, but it is still not ideal b/c it will hold onto the kahadb lock.
> It also can stall shutdown unexpectedly.
> AMQ-7080 is going to tackle checkpointing the free list. This should help
> avoid the need for recovery but it may still be necessary. If the perf hit is
> significant this may need to be optional.
> There will still be the need to walk the index to find the free list.
> It is possible to run with no free list and grow, and we can do that while we
> recover the free list in parallel, then merge the two at a safe point. This
> we can do at startup.
> In cases where the disk is the bottleneck this won't help much, but it will
> help failover and it will help shutdown, with a bit of luck the recovery will
> complete before we stop.
>
> Initially I thought this would be too complex, but if we concede some growth
> while we recover, ie: start with an empty free list, it is should be straight
> forward to merge with a recovered one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
