keith-turner commented on code in PR #3685:
URL: https://github.com/apache/accumulo/pull/3685#discussion_r1291630094
##########
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Tablet.java:
##########
@@ -902,7 +902,60 @@ void initiateClose(boolean saveState) {
log.trace("initiateClose(saveState={}) {}", saveState, getExtent());
MinorCompactionTask mct = null;
+ if (saveState) {
+ try {
+ synchronized (this) {
+ // Wait for any running minor compaction before trying to start
another. This is done for
+ // the case where the current in memory map has a lot of data. So
wait for the running
+ // minor compaction and then start compacting the current in memory
map before closing.
+ getTabletMemory().waitForMinC();
+ }
+ mct = createMinorCompactionTask(getFlushID(),
MinorCompactionReason.CLOSE);
+ } catch (NoNodeException e) {
+ throw new RuntimeException("Exception on " + extent + " during prep
for MinC", e);
+ }
+ }
+
+ if (mct != null) {
+ // Do an initial minor compaction that flushes any data in memory before
marking that tablet
+ // as closed. Another minor compaction will be done once the tablet is
marked as closed. There
+ // are two goals for this initial minor compaction.
+ //
+ // 1. Make the 2nd minor compaction that occurs after closing faster
because it has less
+ // data. That is important because after the tablet is closed it can not
be read or written
+ // to, so hopefully the 2nd compaction has little if any data because of
this minor compaction
+ // that occurred before close.
+ //
+ // 2. Its possible a minor compaction may hang because of bad config or
DFS problems. Taking
+ // this action before close can be less disruptive if it does hang. Also
in the case where
+ // there is a bug that causes minor compaction to fail it will leave the
tablet in a bad
+ // state. If that happens here before starting to close then it could
leave the tablet in a
+ // more usable state than a failure that happens after the tablet starts
to close.
+ //
+ // If 'mct' was null it means either a minor compaction was running,
there was no data to
+ // minor compact, or the flush id was updating. In the case of flush id
was updating, ideally
+ // this code would wait for flush id updates and then minor compact if
needed, but that can
+ // not be done without setting the close state to closing to prevent
flush id updates from
+ // starting. So if there is a flush id update going on it could cause no
minor compaction
+ // here. There will still be a minor compaction after close.
+ //
+ // Its important to run the following minor compaction outside of any
sync blocks as this
+ // could needlessly block scans. The resources needed for the minor
compaction have already
+ // been reserved in a sync block.
+ mct.run();
+ }
+
synchronized (this) {
+
+ if (saveState) {
+ // Wait for any running minc to finish before we start shutting things
down in the tablet.
+ // It is possible that this function was unable to initiate a minor
compaction above and
+ // something else did because of race conditions (because everything
above happens before
+ // marking anything closed so normal actions could still start minor
compactions). If
+ // something did start lets wait on it before marking things closed.
+ getTabletMemory().waitForMinC();
Review Comment:
yeah that is what I would expect to happen
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
