[jira] [Comment Edited] (JCR-4008) Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests

["Woonsan Ko (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15445762#comment-15445762 ] 

Woonsan Ko edited comment on JCR-4008 at 8/31/16 9:17 PM:
----------------------------------------------------------

In the pull request, I fixed the following:
- Restored the delete test method (which had been ignored by overridden method as of JCR-4006).
- Introduced {{AbstractBackend}} base abstract class which is responsible for maintaining async write executor and others such as {{cachingDataStore}} and other configuration related members.
- Let {{S3Backend}}, {{FSBackend}}, {{InMemoryBackend}} and {{VFSBackend}} extend {{AbstractBackend}}. So each of them can take advantage of the new feature of {{AbstractBackend}}: disabling the asynchronous writing if the pool size ({{org.apache.jackrabbit.core.data.AbstractBackend#asyncWritePoolSize}}) is <= zero.
- Disable the asynchronous writing option by setting the pool size property to zero in {{TestCachingFDS.java}}.


was (Author: woon_san):
In the pull request, I fixed the following:
- Restored the delete test method (which had been ignored by overridden method as of JCR-4006).
- Introduced {{AbstractBackend}} base abstract class which is responsible for maintaining async write executor and others such as {{cachingDataStore}} and other configuration related members.
- Let {{S3Backend}}, {{FSBackend}}, {{InMemoryBackend}} and {{VFSBackend}} extend {{AbstractBackend}}. So each of them can take advantage of the new feature of {{AbstractBackend}}: disabling the asynchronous writing if the pool size is <= zero.
- Disable the asynchronous writing option by setting the pool size property to zero in {{TestCachingFDS.java}}.

> Restore TestCachingFDS.testDeleteRecord() to fix it with disabling AsyncUpload in unit tests
> --------------------------------------------------------------------------------------------
>
>                 Key: JCR-4008
>                 URL: https://issues.apache.org/jira/browse/JCR-4008
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.13.2
>            Reporter: Woonsan Ko
>             Fix For: 2.13.3
>
>
> The test used to fail occasionally before the test method was commented out by JCR-4006:
> {noformat}
> junit.framework.AssertionFailedError: rec2 should be null
> 	at junit.framework.Assert.fail(Assert.java:50)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertNull(Assert.java:237)
> 	at org.apache.jackrabbit.core.data.TestCaseBase.doDeleteRecordTest(TestCaseBase.java:327)
> 	at org.apache.jackrabbit.core.data.TestCaseBase.testDeleteRecord(TestCaseBase.java:192)
> {noformat}
> The main reason of this error is because the underlying backend uses asynchronous writing threads by default, which is not working well when extending {{org.apache.jackrabbit.core.data.TestCaseBase}} as mentioned in JCR-4005.
> So, it seems better to fix it again like the following like how JCR-4005 was fixed:
> - Restore the commented out block ({{TestCachingFDS.testDeleteRecord()}}).
> - Provide an option to disable asynchronous writing in all the related backend implementations. e.g., disable it if {{asyncWritePoolSize}} is zero or smaller.
> - In unit tests, simply disable async writing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)