Junit4: टाइमआउट थ्रेडग्रुप को नष्ट नहीं किया जाना चाहिए

क्या आप कृपया एक स्टैकट्रैक और/या ग्रैडल बिल्ड स्कैन प्रदान कर सकते हैं?

कोई JVM क्रैश फ़ाइल या विफलता स्टैकट्रेस नहीं है। कनेक्शन खोने के बारे में केवल एक ग्रहण त्रुटि (java.net.SocketException: कनेक्शन)। जब मैं कमांड लाइन से ग्रैडल में परीक्षण चलाता हूं तो मुझे कोई समस्या नहीं होती है, इसलिए सुनिश्चित नहीं है कि इससे कैसे मदद मिलेगी।

उस स्थिति में, मुझे ग्रहण या एक्लेम्मा समस्या पर संदेह है। क्या आप कृपया इसे उनके साथ ला सकते हैं?

ठीक। एक आखिरी प्रश्न। क्या ऐसा हो सकता है कि जुनीट 4.13 एकीकरण में ग्रहण के साथ कुछ परेशानी हो?

खैर, हमेशा एक मौका होता है कि हमने कुछ तोड़ा। लेकिन जहां तक ​​मुझे पता है, हमने एकीकरण द्वारा उपयोग किए जाने वाले किसी भी एपीआई को नहीं बदला है।

जब मैंने स्टैक ओवरफ्लो पर त्रुटि संदेश की खोज की तो मुझे https://stackoverflow.com/a/42904311/95725 मिला जो इंगित करता है कि यह एक स्मृति समस्या हो सकती है। हो सकता है कि 4.13 में अपग्रेड के साथ आप किसी प्रकार की थ्रेसहोल्ड मेमोरी-वार पार कर लें।

यह भी संभावना है कि आपके क्लासपाथ पर जुनीट के कई संस्करण हों।

हां मैंने कोशिश की कि कोई फायदा नहीं हुआ पोस्ट करने से पहले। इसके अलावा यह केवल उन कैश-विधियों में विफल होने के लिए काफी अजीब है, न कि अन्य 12000+ परीक्षणों के लिए। मैंने अभी तक एक्लेम्मा लोगों से कोई जवाब नहीं सुना है।

नमस्ते। मुझे EclEmma लोगों से कुछ प्रतिक्रिया मिली: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jacoco/SHw3R6cvZSs/yaFgd7XUAQAJ

ऐसा लगता है कि शटडाउन हुक को 4.13 में उसी तरह निष्पादित नहीं किया गया है जैसा कि 4.12 में हुआ करता था और इस प्रकार कवरेज विफलता।

यहां एक जुनीट इस मुद्दे का प्रदर्शन कर रहा है (इसी तरह एक्लेम्मा इसे कैसे करेगा) जो कभी-कभी "हुक निष्पादित" प्रिंट करता है, कभी-कभी 4.13 के साथ नहीं होता है:

import java.util.concurrent.TimeUnit;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.Timeout;

import com.google.common.cache.CacheBuilder;

public class ExampleTest {

  static {
    System.err.println("registering hook");
    Thread thread = new Thread(new Runnable() {
      <strong i="6">@Override</strong>
      public void run() {
        System.err.println("hook executed");
      }
    });
    Runtime.getRuntime().addShutdownHook(thread);
    System.err.println(thread.getThreadGroup());
  }

  <strong i="7">@Rule</strong>
  public Timeout timeout = new Timeout(5, TimeUnit.MINUTES);

  <strong i="8">@Test</strong>
  public void test() {
    CacheBuilder.newBuilder() //
      .<Integer, Object>build();
  }
}

नमस्कार दोस्तों

@akarnokd JaCoCo मेलिंग सूची से मेरी प्रतिक्रियाओं को यहां अग्रेषित करने के लिए धन्यवाद।

@marcphilipp मुझे लगता है कि उपरोक्त उदाहरण के मामले में निम्नलिखित होता है (https://github.com/junit-team/junit4/issues/1652#issuecomment-593559646)।

स्थिर ब्लॉक के निष्पादन के बाद java.lang.ApplicationShutdownHooks.hooks . में एक शटडाउन हुक होता है

{Thread@1552} "Thread[Thread-0,5,main]" -> {Thread@1552} "Thread[Thread-0,5,main]"

और CacheBuilder.newBuilder() के निष्पादन के बाद दो हैं

{LogManager$Cleaner@1551} "Thread[Logging-Cleaner,5,FailOnTimeoutGroup]" -> {LogManager$Cleaner@1551} "Thread[Logging-Cleaner,5,FailOnTimeoutGroup]"
{Thread@1552} "Thread[Thread-0,5,main]" -> {Thread@1552} "Thread[Thread-0,5,main]"

LogManager$Cleaner@1551 java.util.logging.LogManager (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/util/logging/LogManager द्वारा बनाया गया है। .java#L253) क्योंकि com.google.common.cache.CacheBuilder java.util.logging $ का उपयोग करता है (https://github.com/google/guava/blob/v28.2/guava/src/com/google/common/cache/ कैशेबिल्डर.जावा#एल226)।

ध्यान दें कि यह भी FailOnTimeoutGroup से संबंधित है, जिसे org.junit.rules.Timeout (https://github.com/junit-team/junit4/blob/r4.13/src/main/java/org/junit) द्वारा बनाया गया है। /आंतरिक/धावक/कथन/FailOnTimeout.java#L123)।

तो परीक्षण के बाद इस हुक की शुरुआत IllegalThreadStateException (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/lang/Thread.java पर) #L709), क्योंकि समूह पहले ही नष्ट हो चुका है (https://github.com/junit-team/junit4/blob/r4.13/src/main/java/org/junit/internal/runners/statements/FailOnTimeout.java # एल 140)।

यह अपवाद बाद के हुक (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/lang/ApplicationShutdownHooks.java#L101-L103) के निष्पादन को रोकता है और चुपचाप अनदेखा किया जाता है (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/lang/Shutdown.java#L115-L129)।

जिस क्रम में हुक शुरू होते हैं वह keySet पर निर्भर करता है (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/lang/ApplicationShutdownHooks.java#L97 ) IdentityHashMap (https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/lang/ApplicationShutdownHooks.java#L39) का और यही कारण है कि इससे भिन्न होता है दौड़ने के लिए दौड़ें।

JUnit 4.12 के मामले में ऐसा नहीं होता है, क्योंकि FailOnTimeoutGroup का विनाश JUnit 4.13 (https://github.com/junit-team/junit4/commit/63fd27710ee2bab6fdf00965f41ef12b79120c70) में जोड़ा गया था। और यह परिवर्तन निम्न उदाहरण के लिए जांच के दौरान देखे गए 4.12 और 4.13 के बीच के अंतर को भी स्पष्ट करता है (https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jacoco/SHw3R6cvZSs/yaFgd7XUAQAJ):

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.Timeout;

import java.util.concurrent.TimeUnit;

public class ExampleTest {
  <strong i="34">@Rule</strong>
  public Timeout globalTimeout = new Timeout(5, TimeUnit.MINUTES);

  <strong i="35">@Test</strong>
  public final void test() {
    Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
      <strong i="36">@Override</strong>
      public void run() {
        System.err.println("hook executed");
      }
    }));
  }
}

इसे निम्नलिखित के रूप में जुनीट के बिना प्रदर्शित किया जा सकता है

import java.util.logging.LogManager;

public class Example {
  public static void main(String[] args) throws Exception {
    Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
      <strong i="40">@Override</strong>
      public void run() {
        System.err.println("example hook");
      }
    }));

    ThreadGroup group = new ThreadGroup("example group");
    Thread thread = new Thread(group, new Runnable() {
      <strong i="41">@Override</strong>
      public void run() {
        LogManager.getLogManager();
      }
    }, "example thread");
    thread.start();
    thread.join();
    group.destroy();
  }
}

तो मैं ओपनजेडीके में टिकट बनाने के बारे में भी सोच रहा था, और इस तरह के टिकट में क्या सुझाव दिया जा सकता है, इस बारे में सोचते हुए, पहले से मौजूद https://bugs.openjdk.java.net/browse/JDK-6704979

फिर भी सोच रहा था कि जुनीट में इसके बारे में कुछ करने का मौका है या नहीं।

@Godin विस्तृत विश्लेषण के लिए धन्यवाद! मैं

@kcooney क्या आप जानते/याद रखते हैं कि यहां ThreadGroup का उपयोग करने का इरादा क्या था?

@marcphilipp मेरा अनुमान है कि यह टूटना https://github.com/junit-team/junit4/commit/63fd27710 के कारण हुआ था जिसे @ elrodro83 द्वारा प्रस्तावित किया गया था

थ्रेडग्रुप को https://github.com/junit-team/junit4/commit/1768d08d0 में जोड़ा गया था।

@akarnokd वर्कअराउंड के रूप में, क्या आपने JUL को जल्दी शुरू करने की कोशिश की है, उदाहरण के लिए बेस टेस्ट क्लास के स्टैटिक इनिशियलाइज़र में?

नहीं। मैं शायद ही कभी स्थानीय रूप से पूर्ण परियोजना कवरेज चलाता हूं और अब तक, ट्रैविस सीआई कवरेज डेटा तैयार करने में कामयाब रहा है। मैंने उन कैशबिल्डर परीक्षणों पर टिप्पणी करके काम किया, जबकि मुझे परीक्षण की जा रही कक्षा के साथ काम करने की ज़रूरत थी।

63fd277 . के कारण

यानी #1517 बैकलिंक के लिए।

ज़रा सुनिए सभी। @jglick ने #1517 में सुझाव दिया कि हम #1517 को वापस ले लें या इसे ऑप्ट-इन करें।

पीआर #1517 के ThreadGroup.destroy() के साथ मेरा अनुभव भी सकारात्मक नहीं है।

एक्लिप्स कैलिफ़ोर्निया में यह यूनिट परीक्षणों को बेतरतीब ढंग से विफल करने का कारण बनता है।
यादृच्छिकता थ्रेड को समाप्त करने की "दौड़" और ThreadGroup.destroy() की कॉल के कारण होती है।
और टाइमआउट नियम और स्थिर थ्रेडग्रुप के बीच स्पष्ट आदेश की स्थिति भी नहीं है। यदि समूह को टाइमआउट नियम के बाहर त्वरित किया जाता है, तो इसे संरक्षित किया जाता है, अन्यथा नष्ट कर दिया जाता है।

मेरी राय में, यदि ऐसी सुविधा की आवश्यकता है, तो कृपया

1. एक "ऑप्ट-इन" (या "ऑप्ट-आउट") जोड़ें।
2. एक सरल विचार शायद "नष्ट" न हो, यदि कोई उप-समूह "कोई नहीं-डिमन-समूह" है (डेमन समूह अंतिम समाप्ति धागे के साथ नष्ट हो जाते हैं, इन समूहों के लिए विनाश को काम करना चाहिए। किसी भी-डेमन-समूहों के लिए नहीं , यह परेशानी का कारण बन सकता है, अगर ऐसे थ्रेड-ग्रुप नष्ट हो जाते हैं, तो उन्हें शायद स्थिर माना जाता है।)
3. थ्रेड को समाप्त करने के साथ दौड़-स्थिति को रोकें/कम करें। एक विचार शायद "थ्रेड" में शामिल होने से पहले "थ्रेडग्रुप.इंटरप्ट ()" का उपयोग करना है। हो सकता है कि पहले समूहों और उप-समूहों के सभी थ्रेड्स में शामिल होना आवश्यक हो।

अस्थायी कामकाज के रूप में मैं यह सुनिश्चित करने का प्रयास करता हूं कि सभी "स्थैतिक" थ्रेड-समूह किसी भी टाइमआउट नियम से पहले प्रारंभ किए जाते हैं।
लेकिन यह देखना इतना आसान नहीं है।

मुझे लगता है कि इस समस्या की रिपोर्ट की अपेक्षाकृत कम संख्या को देखते हुए सिस्टम प्रॉपर्टी के रूप में ऑप्ट-आउट ध्वज पर्याप्त हो सकता है।

@kcooney आप क्या सुझाव देते हैं कि हम करते हैं?

Timeout नियम में पहले से ही Builder है। FMPOV का उपयोग करना आसान है, अगर वहां कोई पैरामीटर जोड़ा जाता है।

यह संभव है कि 4.13 के कम उपयोग के कारण इस समस्या की कम रिपोर्ट हो। मुझे नहीं लगता कि हमारे पास थ्रेडग्रुप लीकेज की कई रिपोर्टें थीं, और जुनीट 4.12 से थ्रेडग्रुप का उपयोग कर रहा था (देखें https://github.com/junit-team/junit4/commit/1768d08)।

अगर हमने 4.13 जारी नहीं किया होता, तो मैं नए व्यवहार को ऑप्ट-इन करने का सुझाव दूंगा। यदि हम इसे अभी ऑप्ट-इन करते हैं, तो यह एक पर्याप्त परिवर्तन जैसा प्रतीत होता है कि हमें नई रिलीज़ 4.14 करना चाहिए।

अगर हम इसे ऑप्ट इन या ऑप्ट आउट करते हैं, तो मैं सहमत हूं कि हमें बिल्डर का उपयोग करना चाहिए। JUnit 4.x व्यवहार को नियंत्रित करने के लिए शायद ही कभी सिस्टम गुणों का उपयोग करता है, और डेविड सैफ ने अतीत में उन्हें जोड़ने पर आपत्ति जताई है, इसलिए मुझे यकीन नहीं है कि यह एक अच्छा विकल्प है।

मुझे आश्चर्य है कि क्या थ्रेड समूह को नष्ट करने के बजाय हमें इसे केवल एक डेमॉन समूह के रूप में चिह्नित करना चाहिए। मुझे लगता है कि यह मूल मुद्दे को हल करेगा (बाल थ्रेड समूह माता-पिता की डिमन स्थिति का उत्तराधिकारी है) और हम उस परिवर्तन को बग फिक्स रिलीज में कर सकते हैं।

मुझे लगता है कि इसे एक डिमन थ्रेड समूह बनाना एक अच्छा विचार है। क्या यहां किसी के पास पीआर पर काम करने का समय है?

क्या हम किसी तरह इस वजह से 4.13.2 को जल्दी रिहा करने के लिए वोट कर सकते हैं? सुरक्षा मुद्दों <4.13.1 के कारण यह मुझे कुछ हद तक अवरुद्ध कर रहा है। यहां काम के लिए बहुत-बहुत धन्यवाद।

एफवाईआई मेरा न्यूनतम पुनरुत्पादित उदाहरण इस स्टैक ओवरफ्लो पोस्ट और इस जीथब रेपो पर पाया जा सकता है।

@ j256 प्रतिक्रिया के लिए धन्यवाद। हमने अभी तक समयसीमा पर चर्चा नहीं की है। मैंने चीजों को 4.13.2 मील के पत्थर से जोड़ना शुरू कर दिया है।

निम्नलिखित समाधान मेरे लिए काम करता है:

/** Workaround for the already fixed JUnit 4 issue #1652 (<https://github.com/junit-team/junit4/issues/1652>):
 * Can be used in JUnit 4.13 and 4.13.1 in tests with a timeout to prevent the thread group from being destroyed
 * and thus JaCoCo (used e.g. by EclEmma) loosing its collected data. */
public static void workaround_for_junit4_issue_1652() {
    String version = junit.runner.Version.id();
    if (!"4.13.1".equals(version) && !"4.13".equals(version))
        fail("Workaround for JUnit 4 issue #1652 required for JUnit 4.13 and 4.13.1 only; actual version: "
           + version);
    Thread thread = Thread.currentThread();
    if (!"Time-limited test".equals(thread.getName())) fail("Workaround only required for a test with a timeout.");
    new Thread(thread.getThreadGroup(), new Runnable() {
        <strong i="6">@Override</strong>
        public void run() {
            try {
                while (!thread.isInterrupted()) Thread.sleep(100);
            } catch (InterruptedException e) {}
        }
    }).start();
}

@Test(timeout = 42)
public void test() {
    workaround_for_junit4_issue_1652();
    // ...
}

मैं अभी भी इस फिक्स के साथ 4.13.2 की प्रतीक्षा कर रहा हूं। कोई अपडेट @kcooney? फिर से, 4.13.1 से पहले की सुरक्षा समस्याओं के कारण, मैं अब कई परियोजनाओं के साथ फंस गया हूं जो इस बग के कारण सीआई यूनिट परीक्षण जानकारी प्रकाशित नहीं कर रहे हैं। धन्यवाद।

@j256 4.13.2 अब जारी किया गया है।

बहुत बहुत धन्यवाद @marcphilipp !