[hive] branch master updated: HIVE-25970: Missing messages in HS2 operation logs (Stamatis Zampetakis, reviewed by Zoltan Haindrich)

[za...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

zabetak pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/hive.git


The following commit(s) were added to refs/heads/master by this push:
     new d3cd596  HIVE-25970: Missing messages in HS2 operation logs (Stamatis Zampetakis, reviewed by Zoltan Haindrich)
d3cd596 is described below

commit d3cd596aa15ebedd58f99628d43a03eb2f5f3909
Author: Stamatis Zampetakis <za...@gmail.com>
AuthorDate: Wed Feb 23 16:02:27 2022 +0100

    HIVE-25970: Missing messages in HS2 operation logs (Stamatis Zampetakis, reviewed by Zoltan Haindrich)
    
    Revert HIVE-22753 (commit 6a5c0cd04a2e88a545a96d10a942c86b2be18daa).
    
    Preventing the creation of the appender (by returning null) leads to
    the message triggering the creation to be lost forever. Moreover, the
    memory leak that was observed in HIVE-22753 is no longer feasible with
    the fix for HIVE-24590 so the revert is completely safe.
    
    Closes #3048
---
 .../ql/log/HushableRandomAccessFileAppender.java   | 32 ----------------------
 1 file changed, 32 deletions(-)

diff --git a/ql/src/java/org/apache/hadoop/hive/ql/log/HushableRandomAccessFileAppender.java b/ql/src/java/org/apache/hadoop/hive/ql/log/HushableRandomAccessFileAppender.java
index 7e60435..0ff66df 100644
--- a/ql/src/java/org/apache/hadoop/hive/ql/log/HushableRandomAccessFileAppender.java
+++ b/ql/src/java/org/apache/hadoop/hive/ql/log/HushableRandomAccessFileAppender.java
@@ -20,11 +20,7 @@ package org.apache.hadoop.hive.ql.log;
 import java.io.Serializable;
 import java.util.HashMap;
 import java.util.Map;
-import java.util.concurrent.TimeUnit;
 
-import com.google.common.cache.CacheBuilder;
-import com.google.common.cache.CacheLoader;
-import com.google.common.cache.LoadingCache;
 import org.apache.logging.log4j.core.Filter;
 import org.apache.logging.log4j.core.Layout;
 import org.apache.logging.log4j.core.LogEvent;
@@ -51,17 +47,6 @@ import org.apache.logging.log4j.core.util.Integers;
 public final class HushableRandomAccessFileAppender extends
     AbstractOutputStreamAppender<RandomAccessFileManager> {
 
-  private static final LoadingCache<String, String> CLOSED_FILES =
-      CacheBuilder.newBuilder().maximumSize(1000)
-          .expireAfterWrite(1, TimeUnit.SECONDS)
-          .build(new CacheLoader<String, String>() {
-            @Override
-            public String load(String key) throws Exception {
-              return key;
-            }
-          });
-
-
   private final String fileName;
   private Object advertisement;
   private final Advertiser advertiser;
@@ -86,7 +71,6 @@ public final class HushableRandomAccessFileAppender extends
   @Override
   public void stop() {
     super.stop();
-    CLOSED_FILES.put(fileName, fileName);
     if (advertiser != null) {
       advertiser.unadvertise(advertisement);
     }
@@ -188,22 +172,6 @@ public final class HushableRandomAccessFileAppender extends
           + name);
       return null;
     }
-
-    /**
-     * In corner cases (e.g exceptions), there seem to be some race between
-     * com.lmax.disruptor.BatchEventProcessor and HS2 thread which is actually
-     * stopping the logs. Because of this, same filename is recreated and
-     * stop() would never be invoked on that instance, causing a mem leak.
-     * To prevent same file being recreated within very short time,
-     * CLOSED_FILES are tracked in cache with TTL of 1 second. This
-     * also helps in avoiding the stale directories created.
-     */
-    if (CLOSED_FILES.getIfPresent(fileName) != null) {
-      // Do not create another file, which got closed in last 5 seconds
-      LOGGER.error(fileName + " was closed recently.");
-      return null;
-    }
-
     if (layout == null) {
       layout = PatternLayout.createDefaultLayout();
     }