[
https://issues.apache.org/jira/browse/JCR-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467371#comment-15467371
]
Woonsan Ko commented on JCR-4008:
---------------------------------
Hi [~amitjain],
Thank you very much for the review!
I think {{AbstractBackend#createAsyncWriteExecutor()}} actually reads the
{{asyncUploadLimit}} and creates a different executor based on that:
{code}
protected Executor createAsyncWriteExecutor() {
Executor asyncExecutor;
if (cachingDataStore.getAsyncUploadLimit() > 0 &&
getAsyncWritePoolSize() > 0) {
asyncExecutor = (ThreadPoolExecutor)
Executors.newFixedThreadPool(getAsyncWritePoolSize(),
new NamedThreadFactory(getClass().getSimpleName() +
"-write-worker"));
} else {
asyncExecutor = new ImmediateExecutor();
}
return asyncExecutor;
}
{code}
Because I noticed that every {{Backend}} implementation creates a
ThreadPoolExecutor with size of 10 by default in the same way, I moved the
executor creation from each {{Backend}} implementation to the
{{AbstractBackend}} to share the same code in all the {{CachingDataStore}}
related {{Backend}} implementations. Otherwise, I guess we'll need to have the
duplicate code in each Backend.
Maybe do you prefer fixing {{FSBackend.java}} only with the executor creation
code without having to introduce {{AbstractBackend}} yet (maybe another
improvement ticket separately)? In that case, would you please let me know
that? Then I'll update the pull request as soon as possible.
Kind regards,
Woonsan
> 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)
