H2 inability to deal with interrupts

[Paul Taylor]

I have opened this thread to discuss https://github.com/h2database/h2database/issues/227, which has been closed despite no attempt my h2 team to actually fix the issue

[Noel Grandin]

Yeah, because snark is really motivating to volunteer run projects. 

It is fixed. There are several options, ranging from using "async:" to "retry:" to "tcp:".

I suggest "async:" as the best option, followed by "tcp:", "retry:" is really a last-ditch resort because it might interact in weird ways with things like AUTO_SERVER.

There are limited things we can do to affect the behaviour of the Java IO libraries. It unfortunate that they chose to close the FileChannel when a thread is busy doing IO and that thread is interrupted, but that is just the way it is, and we just have the make the best of it.

Perhaps at some point in the future we can make "async:" the default, but I'd like to hear some experience from people actually using it first.

[Paul Taylor]

On Tuesday, 23 July 2019 16:44:35 UTC+1, Noel Grandin wrote:

Yeah, because snark is really motivating to volunteer run projects. 

When you stop comments on an issue its quite irritating since it wasn't a support question but evidence to explain and understand the issue and why it is to fixed. I dont understand why some open source developers seem to think that because the project is opensrc no critism is acceptable.

It is fixed. There are several options, ranging from using "async:" to "retry:" to "tcp:".

This issue was closed without a single mention of async, so if that was the solution it should be explained. You have mentioned in comment to me but with no explanation on how that solves issue, so its all very unclear. Using client-server is not a solution that is just a workaround, not least because according to H2s own perfomance stats its nearly ten times slower http://www.h2database.com/html/performance.html !

[Andrei Tokar]

Paul,

You are very welcome to read the code, understand it and write a little doc page about available options and trade-offs.

BTW, client-server IS a solution, which trades some performance for stability. It may be unsuitable in your situation, but you never bother to describe it either, so why do you expect that someone will spend time laying out all available options?. Nothing is free in this world! This includes all ACID properties performance and of course, software support.

You wrote to Noel, like you are holding some paid support contract with him. My apologies, it it is a case, but mostly people volunteer here and support other users on a "best effort" basis.

[Paul Taylor]

No im sorry  client-server is a WORKAROUND not a SOLUTION, Im using the embedded version and therefore client-server does not fix the problem with the embedded version,  I'm just stating facts.

The other fact is the issue should not be closed unless fixed, if async fixes it then it should be described in the fix. As a user I have spent along time with this problem without being aware of the interrupt issue because it is not documented, because the issue was closed I didnt come across it as its normal practise to only check open issues if using the latest version of software. Its unreasonable to say that if I have an issue the solution is for me to delve down into unfamiliar code to resolve it, having looked at it briefly the async option appears to be the right approach and shows that blaming Java for the problem is misleading, so why is not async not in the documentation at all.

I write opensrc software myself (https://bitbucket.org/ijabz/jaudiotagger/src/master/README.md) so Im aware that its difficult supporting software especially on a voluntarily basis (although many large open src projects to seem to have significant funding) . But with opensrc software precisely because you do not have a support contract and because yo cannot expect anyone to actually solve particular problems for you it is therefore imperative that the issue tracker is correct and not misleading.