When I with ";mv_store=false", a sizeable percentage of the tests fail
with
java.lang.RuntimeException: com.guidewire.pl.system.exception.DBException:
Nested: org.h2.jdbc.JdbcSQLException: IO Exception: "java.io.IOException:
org.h2.jdbc.JdbcSQLException: IO Exception: ""Missing lob entry: 4""
[90028-187]"; "lob: null table: -3 id: 4" [90031-187] EXECUTED SQL [
[exec] [junit] SQLException.getErrorCode() = 90031
[exec] [junit] SQLException.getSQLState() = 90031
[exec] [junit] Connection: jdbc:h2:mem:@name@
[exec] [junit]
[exec] [junit] Top level profiler tag: T:main
[exec] [junit] Isolation level: Read Committed
[exec] [junit] Autocommit: false
[exec] [junit] App server transaction started at: Wed Jun 17
12:15:07 PDT 2015, current time: Wed Jun 17 12:15:08 PDT 2015, _isReadOnly:
true
[exec] [junit] Error executing:
[exec] [junit] SELECT bRoot.ConnectionStarted col0, bRoot.PublicID
col1, bRoot.BgTasksStopped col2, bRoot.BlobData col3,
bRoot.PlannedShutdownTime col4, bRoot.UserSessions col5, bRoot.Env col6,
bRoot.Build col7, bRoot.ConnectionStopped col8,
bRoot.PlannedShutdownInitiated col9, bRoot.LogicalName col10,
bRoot.RunLevel col11, bRoot.Uuid col12, bRoot.ID col13, bRoot.Roles col14,
bRoot.ServerStarted col15, bRoot.ServerId col16, bRoot.LastUpdate col17
FROM px_clustermemberdata bRoot WHERE bRoot.ID = ?
[exec] [junit] Parameters:[5000000001]]
Looking for the "missing lob" message in the H2 discussion group, I see
this has happened in the past, but never saw a resolution.
When I reversed by change that turned off mvStore, these errors went away.
Any other suggestions?
On Tuesday, June 16, 2015 at 9:41:29 AM UTC-7, Thomas Mueller wrote:
>
> Hi,
>
> Looking at the thread dumps, the bottleneck seems to be reading metadata.
> There are two main cases:
>
>
> com.guidewire.pl.system.database.support.H2CatalogSupport.columnExists(H2CatalogSupport.java:81)
>
>
> com.guidewire.pl.system.database.upgrade.BeforeUpgradeColumnImpl.getTypeRepresentationInDatabase(BeforeUpgradeColumnImpl.java:478)
>
> I'm not sure what queries are run, I will try to find out.
>
> It doesn't look related to MVStore or MVCC, but maybe there was a change
> that made it slower. Are you sure it is faster without MVStore? What
> happens if you append ";mv_store=false" to the database URL, and try with
> the latest version?
>
> Regards,
> Thomas
>
> On Friday, June 12, 2015, Wes Clark <[email protected]> wrote:
>
>> We are testing the latest H2 version (from a recent nightly build,
>> actually) in place of a rather ancient but serviceable version 1.2. We are
>> seeing performance degradation of at least a factor of 6. We have suites
>> of test. I can supply you with comparison timings, but for example a suite
>> that takes 20 minutes on the old H2 is timing out after 3 hours. If we
>> don't need MVCC for a suite, we could run it without it. Will that recover
>> the lost time? (That's an experiment I will run later.) We want to take
>> advantage of MVCC (and DBStore) for some integration suites where we hope
>> it will prevent deadlocks. Let me know if you need more details, or if you
>> can respond with general comments about expected performance.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "H2 Database" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/h2-database.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
