-
Notifications
You must be signed in to change notification settings - Fork 140
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
Java: Transaction fails to close if exception is thrown. #149
Comments
This is definitely a bug. I can't clearly see what the cause is, though. The code is using 'finally' to clean up the transaction. Is it possible for you to write a test case? |
@the-real-blackh I ran into this bug in the C# version a while ago. I should have opened an issue when I fixed it. The problem is when an exception happens during the call to |
Hi @the-real-blackh, Unfortunately, it's not happening in my current tests. I haven't been able to reproduce it outside of my existing infrastructure (which is now quite large) and was only able to put an hour into trying today (deadline on the 15th is looming!). I'll put some more effort into figuring out what it is about my architecture that causes this; as an explaination, I have a subclass of StreamSink which diverts sends to a dedicated logic thread, and each UI listener then uses In other words, there's a great deal of untangling to be done to figure out why, exactly, transactions stopped closing; but it always started with a DivZero. I'll refrain from pulling the latest master for the time being, in the hopes that it will reproduce sometime today. |
Alright. It did, in fact, reproduce organically today resulting from CellLoop sampled before looped; An expected error for this test, since I haven't completed implementation. 9d3b648 Fixes the issue. |
Looking through a few other closed issues, I see that the reporter is closing the issue; If you would prefer to close them yourself in the future, just let me know. |
@greyson That's fine! Thank you for that. I've got a few changes to make, then I'll put out a new official release soon with this bug fix in it. |
While I understand that the operations between events should not throw exceptions in a perfect implementation, previous versions would log the exception, abort the transaction, but allow new transactions to be handled. With the newer versions, if there is a single
RuntimeException
, my application ceases to work entirely, as it will no longer acceptsend
on any sink.Having used sodium for numerous android applications; and now using it in a high performance, high throughput Swing application with the current master it's been even more difficult to debug than usual (one side effect of this is that every unit test run after an unrelated unit test causes a transaction to remain open will also fail because no events will propagate).
The text was updated successfully, but these errors were encountered: