You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2021/12/14 20:55:18 UTC

[GitHub] [maven-surefire] findepi commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption

findepi commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r769037716



##########
File path: surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGExecutor.java
##########
@@ -137,6 +152,31 @@ static void run( Iterable<Class<?>> testClasses, String testSourceDirectory,
         testng.run();
     }
 
+    private static void addXmlClass( List<XmlClass> xmlClasses, String testClassName )
+    {
+        XmlClass xmlClass = new XmlClass( testClassName );
+        if ( XML_CLASS_SET_INDEX != null )
+        {
+            try
+            {
+                // In case of parallel test execution with parallel="methods", TestNG orders test execution
+                // by XmlClass.m_index field. When unset (equal for all XmlClass instances), TestNG can
+                // invoke `@BeforeClass` setup methods on many instances, without invoking `@AfterClass`
+                // tearDown methods, thus leading to high resource consumptions when test instances
+                // allocate resources.
+                // With index set, order of setup, test and tearDown methods is reasonable, with approximately
+                // #thread-count many test classes being initialized at given point in time.
+                // Note: XmlClass.m_index field is set automatically by TestNG when it reads a suite file.
+                XML_CLASS_SET_INDEX.invoke( xmlClass, xmlClasses.size() );
+            }
+            catch ( ReflectiveOperationException e )
+            {
+                throw new RuntimeException( e );
+            }
+        }

Review comment:
       The code is compiled against TestNG 5.10 and that version doesn't have the `index` field in `XmlClass`, hence use of reflection.
   
   > Instead of setting the m_index via reflection we could use the appropriate constructor to set it:
   
   Yes, I can lookup a constructor taking `(String.class, int.class)` arguments. It's not as robust or future-proof as finding a `setIndex` method though.




-- 
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-unsubscribe@maven.apache.org

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