Class BatchProcessingCliTest

java.lang.Object
ubic.gemma.apps.BatchProcessingCliTest
public class BatchProcessingCliTest extends Object

  • Constructor Details

    • BatchProcessingCliTest

      public BatchProcessingCliTest()

  • Method Details

    • testParallelCli

      @Test public void testParallelCli()

    • testSequentialCli

      @Test public void testSequentialCli()

    • testParallelAndSequentialCli

      @Test public void testParallelAndSequentialCli()

    • testReporting

      @Test public void testReporting() throws IOException
      Throws:
      IOException

    • testAWarningIsNotAlsoCountedAsASuccess

      @Test public void testAWarningIsNotAlsoCountedAsASuccess()
      🛑 A batch task that reports only a warning has reported. It used to not count, and the executor's "the task said nothing, call it a success" fallback then invented a second row — so a run whose every task was skipped printed a WARNING row and a "Batch task #N" SUCCESS row beside it, and the SUCCESS rows are what a summary gets aggregated by.

    • testEachResultIsWrittenAsItHappensNotOnlyAtTheEnd

      @Test public void testEachResultIsWrittenAsItHappensNotOnlyAtTheEnd()
      🛑 TEXT is the default format, and its grouped summary can only be written at close — it counts and sections the results. That made the whole record live in memory until the run ended, which stopped being survivable when the CLI gained -XX:+ExitOnOutOfMemoryError: that calls os::exit(), so there is no close and no shutdown hook, and a sweep that OOM'd on item 7 of 22 would have lost the record of the six that worked. Worse than the hung JVM the flag was added to prevent.

      Each result is therefore emitted as it happens as well as being grouped at the end. The assertion that matters is the ORDER: a per-result line appears before the summary header, which is only true if it was written during the run rather than assembled at close.