[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106648#comment-15106648
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user andytaylor commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/326#discussion_r50105212
  
--- Diff: 
artemis-journal/src/main/java/org/apache/activemq/artemis/core/journal/impl/JournalFilesRepository.java
 ---
@@ -431,13 +434,16 @@ public JournalFile openFile() throws 
InterruptedException {
  openFilesExecutor.execute(pushOpenRunnable);
   }
 
-  JournalFile nextFile = null;
+  JournalFile nextFile = openedFiles.poll(5, TimeUnit.SECONDS);
+  if (nextFile == null) {
+ 
fileFactory.onIOError(ActiveMQJournalBundle.BUNDLE.fileNotOpened(), "unable to 
open ",  null);
+  }
 
-  while (nextFile == null) {
- nextFile = openedFiles.poll(5, TimeUnit.SECONDS);
- if (nextFile == null) {
-
fileFactory.onIOError(ActiveMQJournalBundle.BUNDLE.fileNotOpened(), "unable to 
open ",  null);
- }
+  if (nextFile == null) {
+  // We need to reconnect the current file with the timed buffer 
as we were not able to roll the file forward
+  // If you don't do this you will get a NPE in 
TimedBuffer::checkSize where it uses the bufferobserver 
+  fileFactory.activateBuffer(journal.getCurrentFile().getFile());
--- End diff --

can you use the BUNDLE here Tom, see ActiveMQJournalBundle.BUNDLE


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107094#comment-15107094
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/326


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106653#comment-15106653
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user tomjenkinson commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172835703
  
I think I made the change you asked for - I will squash it if that is what 
you were asking for.


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106711#comment-15106711
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user andytaylor commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172856746
  
perfect


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106716#comment-15106716
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user tomjenkinson commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172857404
  
Great - I will squash it then thanks


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106697#comment-15106697
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user andytaylor commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172852039
  
not quite tom, 

throw ActiveMQJournalBundle.BUNDLE.someException();


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106718#comment-15106718
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user tomjenkinson commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172857600
  
squished thanks


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106709#comment-15106709
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user tomjenkinson commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172856253
  
any better? I am throwing the one that the IO handler gets too as that 
seems consistent?


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106886#comment-15106886
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172891962
  
will run tests and merge it


> 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)

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107037#comment-15107037
 ] 

ASF GitHub Bot commented on ARTEMIS-351:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/326#issuecomment-172924570
  
There's a checkstyle error, but I will be able to amend before commit.

(Please make sure you rebase against master after I merge this).


> 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)