Skip to content
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

Implements interrupt-safe transaction log #46

Closed
wants to merge 1 commit into from

Conversation

palacsint
Copy link

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 #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
@brettwooldridge
Copy link
Contributor

Unfortunately, by introducing synchronized methods this pull request reverts the disk journal to a sequential write model -- only one thread can write at a time.

To see why this was an issue in 2.1, you can read here.

In 3.0 (SNAPSHOT), the disk journal was re-architected to allow a concurrent write model, with large performance gains. You can read about it here.

Unfortunately, this leaves #45 as yet unresolved, but you now have context if you want to have another go at addressing the issue.

@krokodylowy
Copy link

Palacsint, please attach your results of performace tests described on https://github.com/brettwooldridge/bitronix-hp/wiki/Disk-Journal-Improvements page.

Why don't you make simply patch of original code only with reopenFileChannelIfClosed() method?

@palacsint
Copy link
Author

@krokodylowy, actually we have abandoned this patch and the idea too for a custom SecurityManager which delays interrupts in our application, so interrupts never reach the FileChannel.

I don't really remember why reopenFileChannelIfClose() alone was not enough but looking at the patch again I guess because of the currentPosition field. Feel free to rewrite the patch and I hope the attached tests will show you the case where it's necessary.

@krokodylowy
Copy link

Thanks for response. Can you share your concept of SecurityManager?

ClosedChannelException is serious gap in Bitronix. It can be 'fixed' by better design of user application but CCE still can occur in any moment and can hang enterprise system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TransactionLogAppender's FileChannel is closed on interrupt and never reopened
4 participants