[
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106644#comment-15106644
]
ASF GitHub Bot commented on ARTEMIS-351:
----------------------------------------
GitHub user tomjenkinson opened a pull request:
https://github.com/apache/activemq-artemis/pull/326
ARTEMIS-351 throw an exception if we get an IOException
https://issues.apache.org/jira/browse/ARTEMIS-351
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tomjenkinson/activemq-artemis JBEAP-1987
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/326.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #326
----
commit 33128e1eb845c399b3735120a3b53233adfdc475
Author: Tom Jenkinson <[email protected]>
Date: 2016-01-15T20:55:06Z
ARTEMIS-351 throw an exception if we get an IOException
----
> Report an Exception if a journal file cannot be created rather than blocking
> forever
> ------------------------------------------------------------------------------------
>
> Key: ARTEMIS-351
> URL: https://issues.apache.org/jira/browse/ARTEMIS-351
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Tom Jenkinson
>
> The architecture of the journal component is such that the next journal file
> to create fails (executed async) then the application thread will block
> forever in an append call and the journal will become unusable during that
> JVM execution.
> The error was reported as a warning but the loop is not broken out of after a
> recent change (ARTEMIS-321), a callback IO handler will now be invoked and
> the business logic can elect to make a decision such as shutdown.
> However, if you know that the error may be transient, unless this callback
> throws an unhandled exception the journal will remain blocked forever. Even
> if an unhandled exception is thrown from your handler to unblock the thread,
> there is an issue in that subsequent calls to appendRecord will add the file
> name into the queue of files to create every time it is invoked. This can
> easily result in the same file name appearing twice in the queue. Once this
> happens, the logic to check if a record does not fit in the current file then
> it will fit in the next file triggers and an exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
