java.lang.AssertionError: null

JIRA | ShiqingFan | 1 year ago
  1. 0

    Though running maven test, I find that commit [721ff5839812968832202f4de551efa33e103cc9] of the master branch has a problem: It makes the tachyon.worker.block.meta.CapacityUsageIntegrationTest fails from time to time. When it fails, the log is posted as below: ------------------------------------------------------------------------------- Test set: tachyon.worker.block.meta.CapacityUsageIntegrationTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.685 sec <<< FAILURE! deleteDuringEvictionTest(tachyon.worker.block.meta.CapacityUsageIntegrationTest) Time elapsed: 0.685 sec <<< FAILURE! java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEviction(CapacityUsageIntegrationTest.java:109) at tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEvictionTest(CapacityUsageIntegrationTest.java:117) --------------------- **[TACHYON-759] create a thread pool to handle master removeBlock command **Asynchronous** enables a asynchronous block-deleting behavior of worker. In method `CapacityUsageIntegrationTest#deleteDuringEviction()`: we first create and write a file **filei_1** with size **MEM_CAPACITY_BYTES** in **CACHE_THROUGH** mode, then a command will be sent to worker to delete the **filei_1** **asynchronously**; Next a new **filei_2** with be created and written in the same mode as **filei_2**, while with smaller file size -- **MEM_CAPACITY_BYTES / 4**. Note that the worker deleting behavior is **asynchronous** so we just can't make sure whether **filei_2** could be fully cached in memory or not during this code flow. it's **result is undecidable**. Before merge of TACHYON-759, block removing is finished in a **blocking** way, so all assert works well before. We are **SURE** that the first **Assert.assertTrue(file.isInMemory());** in method `deleteDuringEviction` works well because caller method `deleteDuringEvictionTest()` will sleep for two-heartbeat interval to ensure both the two file deletion to complete for next loop's preparation. Rethink the approach of this test and what it should be testing.

    JIRA | 1 year ago | ShiqingFan
    java.lang.AssertionError: null
  2. 0

    Though running maven test, I find that commit [721ff5839812968832202f4de551efa33e103cc9] of the master branch has a problem: It makes the tachyon.worker.block.meta.CapacityUsageIntegrationTest fails from time to time. When it fails, the log is posted as below: ------------------------------------------------------------------------------- Test set: tachyon.worker.block.meta.CapacityUsageIntegrationTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.685 sec <<< FAILURE! deleteDuringEvictionTest(tachyon.worker.block.meta.CapacityUsageIntegrationTest) Time elapsed: 0.685 sec <<< FAILURE! java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEviction(CapacityUsageIntegrationTest.java:109) at tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEvictionTest(CapacityUsageIntegrationTest.java:117) --------------------- **[TACHYON-759] create a thread pool to handle master removeBlock command **Asynchronous** enables a asynchronous block-deleting behavior of worker. In method `CapacityUsageIntegrationTest#deleteDuringEviction()`: we first create and write a file **filei_1** with size **MEM_CAPACITY_BYTES** in **CACHE_THROUGH** mode, then a command will be sent to worker to delete the **filei_1** **asynchronously**; Next a new **filei_2** with be created and written in the same mode as **filei_2**, while with smaller file size -- **MEM_CAPACITY_BYTES / 4**. Note that the worker deleting behavior is **asynchronous** so we just can't make sure whether **filei_2** could be fully cached in memory or not during this code flow. it's **result is undecidable**. Before merge of TACHYON-759, block removing is finished in a **blocking** way, so all assert works well before. We are **SURE** that the first **Assert.assertTrue(file.isInMemory());** in method `deleteDuringEviction` works well because caller method `deleteDuringEvictionTest()` will sleep for two-heartbeat interval to ensure both the two file deletion to complete for next loop's preparation. Rethink the approach of this test and what it should be testing.

    JIRA | 1 year ago | ShiqingFan
    java.lang.AssertionError: null
  3. 0

    Graph Database Kernel TEST failure

    GitHub | 2 years ago | antonio-castellon
    java.lang.AssertionError: null
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    TEST FAILURE - com.hazelcast.map.SizeEstimatorTest.testPutRemove

    GitHub | 3 years ago | mdogan
    java.lang.AssertionError: null

  1. michallos 34 times, last 5 days ago
  2. andyglick 2 times, last 3 months ago
  3. WoodenDoors 2 times, last 9 months ago
10 unregistered visitors
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis

  1. java.lang.AssertionError

    null

    at org.junit.Assert.fail()
  2. JUnit
    Assert.assertTrue
    1. org.junit.Assert.fail(Assert.java:86)
    2. org.junit.Assert.assertTrue(Assert.java:41)
    3. org.junit.Assert.assertTrue(Assert.java:52)
    3 frames
  3. tachyon.worker.block
    CapacityUsageIntegrationTest.deleteDuringEvictionTest
    1. tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEviction(CapacityUsageIntegrationTest.java:109)
    2. tachyon.worker.block.meta.CapacityUsageIntegrationTest.deleteDuringEvictionTest(CapacityUsageIntegrationTest.java:117)
    2 frames