"Unexpected code path" error

[Christopher Ekberg]

I occasionally get an exception from H2 with "Unexpected code path".
It's not easily reproducible in my application, and I don't have a
concise test program to demonstrate it, but I've excerpted the stack
trace in hopes that it's enough to figure out the bug.

I'm using H2 1.0.77, which is being called through a product called
Sequoia - you can ignore the parts of the stack trace below which are
from Sequoia.

URL = jdbc:h2:file:/some/
db
;IFEXISTS
=TRUE;DB_CLOSE_ON_EXIT=FALSE;CIPHER=AES;FILE_LOCK=SOCKET;MVCC=true

General error: java.lang.RuntimeException: Unexpected code path; SQL
statement:
select this_.id as id6_1_, this_.emailAddress as emailAdd2_6_1_,
this_.emailSession_id as emailSes7_6_1_, this_.fromAccountId as
fromAcco3_6_1_, this_.messageId as messageId6_1_, this_.sent as
sent6_1_, this_.toAccountId as toAccoun6_6_1_,
substitute2_.queuedMessage_id as queuedMe4_3_, substitute2_.id as
id3_, substitute2_.id as id7_0_, substitute2_.field as field7_0_,
substitute2_.queuedMessage_id as queuedMe4_7_0_, substitute2_.value as
value7_0_ from QueuedMessage this_ left outer join
QueuedMessageFieldValue substitute2_ on
this_.id=substitute2_.queuedMessage_id where this_.emailSession_id=?
and this_.id>? order by this_.id asc limit ? [50000-77]
at org.h2.message.Message.getSQLException(Message.java:103)
at org.h2.message.Message.convert(Message.java:257)
at org.h2.message.Message.convert(Message.java:228)
at org.h2.command.Command.executeQueryLocal(Command.java:142)
at org.h2.command.Command.executeQuery(Command.java:121)
at
org
.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:
96)
...
Caused-by
org
.continuent
.sequoia.common.exceptions.driver.protocol.SerializableException:
Unexpected code path
at org.h2.message.Message.getInternalError(Message.java:179)
at org.h2.message.Message.getInternalError(Message.java:280)
at
org.h2.index.MultiVersionCursor.next(MultiVersionCursor.java:144)
at org.h2.table.TableFilter.next(TableFilter.java:297)
at org.h2.table.TableFilter.next(TableFilter.java:282)
at org.h2.command.dml.Select.queryFlat(Select.java:471)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:539)
at org.h2.command.dml.Query.query(Query.java:233)
at
org.h2.command.CommandContainer.query(CommandContainer.java:79)
at org.h2.command.Command.executeQueryLocal(Command.java:140)
at org.h2.command.Command.executeQuery(Command.java:121)
at
org
.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:
96)
...

Does this help?

Thanks,
Chris

[Thomas Mueller]

Hi,

> I'm using H2 1.0.77

There were some changes in the MVCC code in version 1.0.79. Did you
try using this or a newer version?

> FILE_LOCK=SOCKET

Is this important for you? I don't think it is related to the problem,
but I like to understand why you need it.

Regards,
Thomas

[Christopher Ekberg]

The MVCC row level locking seemed like a big enough change which could
change the dynamics of our application enough that we weren't ready to
switch, although I'll be starting testing using it shortly. Were
there other MVCC bug fixes in or since that release as well? I didn't
see them in the release notes.

Regarding FILE_LOCK=SOCKET: each of our VMs has up to 30 active H2
databases, so we didn't want 30 extra threads per VM reading files
every 5 seconds. I seem to recall we switched to socket locking from
file locking due to some sort of slowdown, maybe a block waiting for a
file lock on database startup? Don't quite remember, unfortunately.

Thanks,
Chris

[Thomas Mueller]

Hi,

> The MVCC row level locking seemed like a big enough change which could
> change the dynamics of our application enough that we weren't ready to
> switch, although I'll be starting testing using it shortly. Were
> there other MVCC bug fixes in or since that release as well? I didn't
> see them in the release notes.

No, all bugfixes are listed in the change log.

Could you provide some more information about your use case? I would
like to know the settings, the table definitions (SCRIPT NODATA would
list that). How many concurrent connection to the same database do you
have, and what is the access pattern?

> Regarding FILE_LOCK=SOCKET: each of our VMs has up to 30 active H2
> databases, so we didn't want 30 extra threads per VM reading files
> every 5 seconds. I seem to recall we switched to socket locking from
> file locking due to some sort of slowdown, maybe a block waiting for a
> file lock on database startup? Don't quite remember, unfortunately.

That's OK. The socket locking should work, however I think the default
file locking should also work - if it doesn't I would be interested to
understand why.

Regards,
Thomas