[GitHub] [hbase] sunhelly commented on a diff in pull request #4725: HBASE-27152 Under compaction mark may leak

[GitBox]

sunhelly commented on code in PR #4725:
URL: https://github.com/apache/hbase/pull/4725#discussion_r955709921


##
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplit.java:
##
@@ -382,15 +381,20 @@ protected void requestCompactionInternal(HRegion region, 
HStore store, String wh
   // pool; we will do selection there, and move to large pool if necessary.
   pool = shortCompactions;
 }
-pool.execute(
-  new CompactionRunner(store, region, compaction, tracker, 
completeTracker, pool, user));
+
+// A simple implementation for under compaction marks.
+// Since this method is always called in the synchronized methods, we do 
not need to use the
+// boolean result to make sure that exactly the one that added here will 
be removed
+// in the next steps.
+underCompactionStores.add(getStoreNameForUnderCompaction(store));

Review Comment:
   Yes, the compaction mark adding and removing operations are in different 
threads, we can't avoid the latter removing thread excuting faster than the 
former adding thread. Let the marks be added before the compaction runner tasks 
be added to the thread pool can keep the correct order.



-- 
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: issues-unsubscr...@hbase.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [hbase] sunhelly commented on a diff in pull request #4725: HBASE-27152 Under compaction mark may leak

[GitBox]

sunhelly commented on code in PR #4725:
URL: https://github.com/apache/hbase/pull/4725#discussion_r955705347


##
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplit.java:
##
@@ -145,15 +144,15 @@ private void createCompactionExecutors() {
 final String n = Thread.currentThread().getName();
 
 StealJobQueue stealJobQueue = new 
StealJobQueue(COMPARATOR);
+// Since the StealJobQueue is unbounded, we need not to set the 
RejectedExecutionHandler for

Review Comment:
   Actually the max size of StealJobQueue is bouded by the VM limit of an 
array, and the OOM exception occurs before the rejection handler. So 
StealJobQueue is equivalent to be unbounded. I think the RejectionHandler may 
bring some confusions and make the codes a little puzzle. 
   I will seperate the removing the rejection handler here in another issue. 
Thanks.



-- 
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: issues-unsubscr...@hbase.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org