LiXin Ge updated HDDS-347:
    Status: Patch Available  (was: Open)

> Ozone Integration Tests : testCloseContainerViaStandaAlone fails sometimes
> --------------------------------------------------------------------------
>                 Key: HDDS-347
>                 URL: https://issues.apache.org/jira/browse/HDDS-347
>             Project: Hadoop Distributed Data Store
>          Issue Type: Bug
>            Reporter: LiXin Ge
>            Assignee: LiXin Ge
>            Priority: Major
>         Attachments: HDDS-347.000.patch
> This issue was finded in the automatic JenKins unit test of HDDS-265.
>  The container life cycle state is : Open -> Closing -> closed, this test 
> submit the container close command and wait for container state change to 
> *not equal to open*, actually even when the state condition(not equal to 
> open) is satisfied, the container may still in process of closing, so the LOG 
> which will printf after the container closed can't be find sometimes and the 
> test fails.
> {code:java|title=KeyValueContainer.java|borderStyle=solid}
>     try {
>       writeLock();
>       containerData.closeContainer();
>       File containerFile = getContainerFile();
>       // update the new container data to .container File
>       updateContainerFile(containerFile);
>     } catch (StorageContainerException ex) {
> {code}
> Looking at the code above, the container state changes from CLOSING to CLOSED 
> in the first step, the remaining *updateContainerFile* may take hundreds of 
> milliseconds, so even we modify the test logic to wait for the *CLOSED* state 
> will not guarantee the test success, too.
>  These are two way to fix this:
>  1, Remove one of the double check which depends on the LOG.
>  2, If we have to preserve the double check, we should wait for the *CLOSED* 
> state and sleep for a while to wait for the LOG appears.
>  patch 000 is based on the second way.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to