Whilst it's not optimal it's not a bug either. The flag to end refers to the work on the branch rather than to the tx outcome. The sequence end(success); rollback(); is valid and will occur not only from the reaper timeout but also in a normal tx termination where a prepare on another resource fails and the tm executes a rollback. Therefore, whilst we could change the reaper (and the normal rollback path, which is largely the same) to use end(fail), your code is going to have to cope with end(success); rollback() anyhow.
The problem is that the TM is calling commit() through topLevel somehow.
And it's weird that the client is getting a can't commit exception but the resource.commit() was already called by the time the exception was caught.
Scratch what I said about the commit being called anyway. I will do some debug and provide some input in 10 minutes.
There's definitely something weird going on though.
Ok, I see what you mean. Rollback is being called properly.
The bug is probably on HornetQ then. i will investigate a bit more. I will come back later if I see any other thing wrong about this.
Thanks for the help