-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TransactionLogAppender's FileChannel is closed on interrupt and never reopened #45
Comments
When an interrupt happened on a thread during writing the transaction log, the underlying FileChannel was closed as a result. Any further use (even from another threads) threw a java.nio.channels.ClosedChannelException rendering the transaction manager unusable since the transaction logs were never reopened. This commit changes this behavior, log file operations reopen the file if it was closed by an interrupt of another thread. fixes scalar-labs#45 Commit by Tibor Billes, Miklós Karakó, Balázs Póka
When an interrupt happened on a thread during writing the transaction log, the underlying FileChannel was closed as a result. Any further use (even from another threads) threw a java.nio.channels.ClosedChannelException rendering the transaction manager unusable since the transaction logs were never reopened. This commit changes this behavior, log file operations reopen the file if it was closed by an interrupt of another thread. fixes scalar-labs#45 Commit by Tibor Billes, Miklós Karakó, Balázs Póka
When an interrupt happened on a thread during writing the transaction log, the underlying FileChannel was closed as a result. Any further use (even from another threads) threw a java.nio.channels.ClosedChannelException rendering the transaction manager unusable since the transaction logs were never reopened. This commit changes this behavior, log file operations reopen the file if it was closed by an interrupt of another thread. fixes scalar-labs#45 Commit by Tibor Billes, Miklós Karakó, Balázs Póka
When an interrupt happened on a thread during writing the transaction log, the underlying FileChannel was closed as a result. Any further use (even from another threads) threw a java.nio.channels.ClosedChannelException rendering the transaction manager unusable since the transaction logs were never reopened. This commit changes this behavior, log file operations reopen the file if it was closed by an interrupt of another thread. fixes scalar-labs#45 Commit by Tibor Billes, Miklós Karakó, Balázs Póka
According to old "Multithreaded Programming with JAVA™ Technology" avoid interruption and cancellation if at all possible. |
There is an ugly workaround that would work: when you get such ClosedChannelException - which can be done by checking the root cause of the exception - clearing the interrupt flag then closing and reopening the disk journal will make BTM resume where it left, ie:
You'll get some error in the logs complaining that the journal couldn't be properly closed but all aborted transactions should be recovered and new ones should start flowing again happily. This is not ideal, but should safely work around the problem. |
Thanks. We will try. |
threadPoolExecutor.shutdownNow() that is too brutal See scalar-labs/btm#45 for explainations...
threadPoolExecutor.shutdownNow() that is too brutal See scalar-labs/btm#45 for explainations...
We had the same issue. @lorban , thank you for the solution. |
The team behind BTM moved off to other horizons, BTM has been unmaintained for a few years now and is still looking for someone to take over its maintenance. For as long as this will be the case, no bug fixes nor new features will be made. |
When an interrupt happens on a thread during writing the transaction log, the underlying FileChannel is closed as a result. Any further use will throw a java.nio.channels.ClosedChannelException rendering the transaction manager unusable since the transaction logs are never reopened. The main issue here is that no other threads can use it any more.
Are there any solutions to situations like this?
The text was updated successfully, but these errors were encountered: