Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hi, I would need a reproducible test case. Regards, Thomas On Tuesday, May 20, 2014, too wrote: > Hi, > Sometimes when our application is shut down forcibly it is unable to start > again with exceptions below. It does not appear that transaction is in > progress at the time of shutdown but I can not be sure. I was unable to > create test case but our application reproduces this quite consistently > (it's very rare that it starts after being terminated). > I have attached debug trace file for failed start - not for the shutdown. > I tried INFO logging for shutdown (breaking the db) but nothing seemed > interesting there, just bunch of selects. Also no error is logged during > shutdown or startup. > > Environment details are > >- H2 - 1.3.176 >- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, >32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode) >- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) >- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE > > > NullPointerException - this is what usually happens > > org.h2.jdbc.JdbcSQLException: General error: > "java.lang.NullPointerException" [5-176] > at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) > ~[h2.jar:1.3.176] > at org.h2.message.DbException.get(DbException.java:167) ~[h2.jar:1.3.176] > at org.h2.message.DbException.convert(DbException.java:294) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.openDatabase(Database.java:291) ~[h2.jar:1.3.176] > at org.h2.engine.Database.(Database.java:254) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176] > at > org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:331) > ~[h2.jar:1.3.176] > at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:107) > ~[h2.jar:1.3.176] > at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:91) > ~[h2.jar:1.3.176] > at org.h2.Driver.connect(Driver.java:74) ~[h2.jar:1.3.176] > at java.sql.DriverManager.getConnection(DriverManager.java:579) > ~[na:1.7.0_17] > at java.sql.DriverManager.getConnection(DriverManager.java:221) > ~[na:1.7.0_17] > at ... > ... 12 common frames omitted > Caused by: java.lang.NullPointerException: null > at org.h2.store.PageStore.removeMeta(PageStore.java:1642) ~[h2.jar:1.3.176] > at org.h2.store.PageStore.redo(PageStore.java:1565) ~[h2.jar:1.3.176] > at org.h2.store.PageStore.redoDelete(PageStore.java:1550) ~[h2.jar:1.3.176] > at org.h2.store.PageLog.recover(PageLog.java:347) ~[h2.jar:1.3.176] > at org.h2.store.PageStore.recover(PageStore.java:1407) ~[h2.jar:1.3.176] > at org.h2.store.PageStore.openExisting(PageStore.java:368) > ~[h2.jar:1.3.176] > at org.h2.store.PageStore.open(PageStore.java:289) ~[h2.jar:1.3.176] > at org.h2.engine.Database.getPageStore(Database.java:2366) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.open(Database.java:657) ~[h2.jar:1.3.176] > at org.h2.engine.Database.openDatabase(Database.java:260) ~[h2.jar:1.3.176] > ... 25 common frames omitted > > > ArrayIndexOutOfBoundsException - I got this one only once > > Caused by: org.h2.jdbc.JdbcSQLException: General error: > "java.lang.ArrayIndexOutOfBoundsException: 44" [5-176] > at > org.h2.message.DbException.getJdbcSQLException(DbException.java:344) > ~[h2.jar:1.3.176] > at org.h2.message.DbException.get(DbException.java:167) > ~[h2.jar:1.3.176] > at org.h2.message.DbException.convert(DbException.java:294) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.openDatabase(Database.java:291) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.(Database.java:254) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:57) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:164) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:125) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:27) > ~[h2.jar:1.3.176] > at > org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:331) > ~[h2.jar:1.3.176] > at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:107) > ~[h2.jar:1.3.176] > at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:91) > ~[h2.jar:1.3.176] > at org.h2.Driver.connect(Driver.java:74) ~[h2.jar:1.3.176] > at java.sql.DriverManager.getConnection(DriverManager.java:579) > ~[na:1.7.0_17] > at java.sql.DriverManager.getConnection(DriverManager.java:221) > ~[na:1.7.0_17] > at > com.stsjava.fieldit.dbdrv.dbjdbc.DbJdbcDataToolkit.createConnection(DbJdbcData
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hi, I could analyze it now. The problem seems to be that creating a temporary table is not committed, and then the temporary table is deleted in another session. I have a fix / workaround for that, but so far no test case. Please tell me if you have a reproducible test case. Regards, Thomas On Tuesday, May 27, 2014, too wrote: > Even though I can reproduce this with our app I fail to create separate > test case to reproduce the problem (i.e. to break the DB). What I can do is > send you database that H2 fails to open. Perhaps it is not really bug > during close but not robust enough recovery during startup. Zipped DB has > 10MB and I can share it for you privately if you think that can help > > thanks > Tono > > On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote: > > I have experimented with this a little and here are few notes > >- lock file remains in place - this is consistent with shutdown hooks >not being executed during JVM abort >- size of DB file remains intact during runtime but during process >termination the size rises by approximately 50MB - which contradicts >previous point and it seems there is something executed during abort >- I can replicate problem with 100% success rate using our app but I >fail to create test app to replicate the problem (still have a few ideas to >try) >- I can replicate the problem with older 1.3.x releases as well as >with latest 1.4.x release (with MV_STORE=FALSE) >- even though I do not think that there are transactions in progress >at the time of termination it is possible there are open cursors or >something similar - read-related > > I can avoid this problem by running H2 in server mode but that is not what > I want. > > Tono > > On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote: > > Hi, > Sometimes when our application is shut down forcibly it is unable to start > again with exceptions below. It does not appear that transaction is in > progress at the time of shutdown but I can not be sure. I was unable to > create test case but our application reproduces this quite consistently > (it's very rare that it starts after being terminated). > I have attached debug trace file for failed start - not for the shutdown. > I tried INFO logging for shutdown (breaking the db) but nothing seemed > interesting there, just bunch of selects. Also no error is logged during > shutdown or startup. > > Environment details are > >- H2 - 1.3.176 >- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, >32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode) >- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) >- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE > > > NullPointerException - this is what usually happens > > org.h2.jdbc.JdbcSQLException: General error: "java.lang.NullPointerException" > [5-176] > at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) > ~[h2.jar:1.3.176] > at org.h2.message.DbException.get(DbException.java:167) ~[h2.jar:1.3.176] > at org.h2.message.DbException.convert(DbException.java:294) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.openDatabase(Database.java:291) > ~[h2.jar:1.3.176] > at org.h2.engine.Database.(Database.java:254) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) > ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176] > at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176] > > -- > 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 h2-database+unsubscr...@googlegroups.com > > . > To post to this group, send email to h2-database@googlegroups.com > . > 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hello, I can test the fix for you easily, all I need is h2 jar with fix. Regarding the test I tried all I could think of. Our app is fairly large (15MB jar of classes with lots of framework-ish stuff happening in the background) so it is difficult to point out the scenario. Tried INFO logging to re-execute the same set of queries but that has not replicated the problem. I am also pretty sure we do not create any temporary tables explicitly (also searched code-base for "create memory table"). Can you point me in some direction as what to look for? I mean what would you expect to be happening to create the table? Does H2 create temp tables implicitly? All we do to trigger the problem are select queries (based on the info log I had). thanks Tono On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote: > > Hi, > > I could analyze it now. The problem seems to be that creating a temporary > table is not committed, and then the temporary table is deleted in another > session. I have a fix / workaround for that, but so far no test case. > Please tell me if you have a reproducible test case. > > Regards, > Thomas > > > > On Tuesday, May 27, 2014, too > wrote: > >> Even though I can reproduce this with our app I fail to create separate >> test case to reproduce the problem (i.e. to break the DB). What I can do is >> send you database that H2 fails to open. Perhaps it is not really bug >> during close but not robust enough recovery during startup. Zipped DB has >> 10MB and I can share it for you privately if you think that can help >> >> thanks >> Tono >> >> On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote: >> >> I have experimented with this a little and here are few notes >> >>- lock file remains in place - this is consistent with shutdown hooks >>not being executed during JVM abort >>- size of DB file remains intact during runtime but during process >>termination the size rises by approximately 50MB - which contradicts >>previous point and it seems there is something executed during abort >>- I can replicate problem with 100% success rate using our app but I >>fail to create test app to replicate the problem (still have a few ideas >> to >>try) >>- I can replicate the problem with older 1.3.x releases as well as >>with latest 1.4.x release (with MV_STORE=FALSE) >>- even though I do not think that there are transactions in progress >>at the time of termination it is possible there are open cursors or >>something similar - read-related >> >> I can avoid this problem by running H2 in server mode but that is not >> what I want. >> >> Tono >> >> On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote: >> >> Hi, >> Sometimes when our application is shut down forcibly it is unable to >> start again with exceptions below. It does not appear that transaction is >> in progress at the time of shutdown but I can not be sure. I was unable to >> create test case but our application reproduces this quite consistently >> (it's very rare that it starts after being terminated). >> I have attached debug trace file for failed start - not for the shutdown. >> I tried INFO logging for shutdown (breaking the db) but nothing seemed >> interesting there, just bunch of selects. Also no error is logged during >> shutdown or startup. >> >> Environment details are >> >>- H2 - 1.3.176 >>- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, >>32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode) >>- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) >>- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE >> >> >> NullPointerException - this is what usually happens >> >> org.h2.jdbc.JdbcSQLException: General error: >> "java.lang.NullPointerException" >> [5-176] >> at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) >> ~[h2.jar:1.3.176] >> at org.h2.message.DbException.get(DbException.java:167) >> ~[h2.jar:1.3.176] >> at org.h2.message.DbException.convert(DbException.java:294) >> ~[h2.jar:1.3.176] >> at org.h2.engine.Database.openDatabase(Database.java:291) >> ~[h2.jar:1.3.176] >> at org.h2.engine.Database.(Database.java:254) ~[h2.jar:1.3.176] >> at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176] >> at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176] >> at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) >> ~[h2.jar:1.3.176] >> at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176] >> at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176] >> >> -- >> 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 h2-database+unsubscr...@googlegroups.com. >> To post to this group, send email to h2-database@googlegroups.com. >> Visit this group at http:/
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hi, The latest build is available at: http://h2database.com/html/build.html#automated > Can you point me in some direction as what to look for? If you don't create temporary tables, then most likely the problem is large result sets, as in some cases this will implicitly create temporary tables. I found out this week that this was not well tested so far. I found a way to better test it, and found a number of issues. I had to fix and partially re-write this area, so I believe this will be resolved in the next release. Regards, Thomas On Tue, Jun 3, 2014 at 10:58 AM, too wrote: > Hello, > I can test the fix for you easily, all I need is h2 jar with fix. > > Regarding the test I tried all I could think of. Our app is fairly large > (15MB jar of classes with lots of framework-ish stuff happening in the > background) so it is difficult to point out the scenario. Tried INFO > logging to re-execute the same set of queries but that has not replicated > the problem. I am also pretty sure we do not create any temporary tables > explicitly (also searched code-base for "create memory table"). > > Can you point me in some direction as what to look for? I mean what would > you expect to be happening to create the table? Does H2 create temp tables > implicitly? All we do to trigger the problem are select queries (based on > the info log I had). > > thanks > Tono > > On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote: > >> Hi, >> >> I could analyze it now. The problem seems to be that creating a temporary >> table is not committed, and then the temporary table is deleted in another >> session. I have a fix / workaround for that, but so far no test case. >> Please tell me if you have a reproducible test case. >> >> Regards, >> Thomas >> >> >> >> On Tuesday, May 27, 2014, too wrote: >> >>> Even though I can reproduce this with our app I fail to create separate >>> test case to reproduce the problem (i.e. to break the DB). What I can do is >>> send you database that H2 fails to open. Perhaps it is not really bug >>> during close but not robust enough recovery during startup. Zipped DB has >>> 10MB and I can share it for you privately if you think that can help >>> >>> thanks >>> Tono >>> >>> On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote: >>> >>> I have experimented with this a little and here are few notes >>> >>>- lock file remains in place - this is consistent with shutdown >>>hooks not being executed during JVM abort >>>- size of DB file remains intact during runtime but during process >>>termination the size rises by approximately 50MB - which contradicts >>>previous point and it seems there is something executed during abort >>>- I can replicate problem with 100% success rate using our app but I >>>fail to create test app to replicate the problem (still have a few ideas >>> to >>>try) >>>- I can replicate the problem with older 1.3.x releases as well as >>>with latest 1.4.x release (with MV_STORE=FALSE) >>>- even though I do not think that there are transactions in progress >>>at the time of termination it is possible there are open cursors or >>>something similar - read-related >>> >>> I can avoid this problem by running H2 in server mode but that is not >>> what I want. >>> >>> Tono >>> >>> On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote: >>> >>> Hi, >>> Sometimes when our application is shut down forcibly it is unable to >>> start again with exceptions below. It does not appear that transaction is >>> in progress at the time of shutdown but I can not be sure. I was unable to >>> create test case but our application reproduces this quite consistently >>> (it's very rare that it starts after being terminated). >>> I have attached debug trace file for failed start - not for the >>> shutdown. I tried INFO logging for shutdown (breaking the db) but nothing >>> seemed interesting there, just bunch of selects. Also no error is logged >>> during shutdown or startup. >>> >>> Environment details are >>> >>>- H2 - 1.3.176 >>>- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, >>>32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode) >>>- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) >>>- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE >>> >>> >>> NullPointerException - this is what usually happens >>> >>> org.h2.jdbc.JdbcSQLException: General error: "java.lang. >>> NullPointerException" [5-176] >>> at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) >>> ~[h2.jar:1.3.176] >>> at org.h2.message.DbException.get(DbException.java:167) >>> ~[h2.jar:1.3.176] >>> at org.h2.message.DbException.convert(DbException.java:294) >>> ~[h2.jar:1.3.176] >>> at org.h2.engine.Database.openDatabase(Database.java:291) >>> ~[h2.jar:1.3.176] >>> at org.h2.engine.Database.(Database.java:254) ~[h2.jar:1.3.176] >>> at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176]
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hi, I tested with the 1.3.178 and I can confirm that it resolved problem. Tried twice with new jar and problem has not occurred, then tried back with 1.3.176 and replicated it immediately. With "damaged" DB then tried the new jar and it recovered just fine. I consider this fixed now, thank you! Looking forward for next release and will use the new jar in the meantime thanks Tono On Wednesday, June 4, 2014 8:52:08 PM UTC+2, Thomas Mueller wrote: > > Hi, > > The latest build is available at: > http://h2database.com/html/build.html#automated > > > Can you point me in some direction as what to look for? > > If you don't create temporary tables, then most likely the problem is > large result sets, as in some cases this will implicitly create temporary > tables. I found out this week that this was not well tested so far. I found > a way to better test it, and found a number of issues. I had to fix and > partially re-write this area, so I believe this will be resolved in the > next release. > > Regards, > Thomas > > > > On Tue, Jun 3, 2014 at 10:58 AM, too > > wrote: > >> Hello, >> I can test the fix for you easily, all I need is h2 jar with fix. >> >> Regarding the test I tried all I could think of. Our app is fairly large >> (15MB jar of classes with lots of framework-ish stuff happening in the >> background) so it is difficult to point out the scenario. Tried INFO >> logging to re-execute the same set of queries but that has not replicated >> the problem. I am also pretty sure we do not create any temporary tables >> explicitly (also searched code-base for "create memory table"). >> >> Can you point me in some direction as what to look for? I mean what would >> you expect to be happening to create the table? Does H2 create temp tables >> implicitly? All we do to trigger the problem are select queries (based on >> the info log I had). >> >> thanks >> Tono >> >> On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote: >> >>> Hi, >>> >>> I could analyze it now. The problem seems to be that creating a >>> temporary table is not committed, and then the temporary table is deleted >>> in another session. I have a fix / workaround for that, but so far no test >>> case. Please tell me if you have a reproducible test case. >>> >>> Regards, >>> Thomas >>> >>> >>> >>> On Tuesday, May 27, 2014, too wrote: >>> Even though I can reproduce this with our app I fail to create separate test case to reproduce the problem (i.e. to break the DB). What I can do is send you database that H2 fails to open. Perhaps it is not really bug during close but not robust enough recovery during startup. Zipped DB has 10MB and I can share it for you privately if you think that can help thanks Tono On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote: I have experimented with this a little and here are few notes - lock file remains in place - this is consistent with shutdown hooks not being executed during JVM abort - size of DB file remains intact during runtime but during process termination the size rises by approximately 50MB - which contradicts previous point and it seems there is something executed during abort - I can replicate problem with 100% success rate using our app but I fail to create test app to replicate the problem (still have a few ideas to try) - I can replicate the problem with older 1.3.x releases as well as with latest 1.4.x release (with MV_STORE=FALSE) - even though I do not think that there are transactions in progress at the time of termination it is possible there are open cursors or something similar - read-related I can avoid this problem by running H2 in server mode but that is not what I want. Tono On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote: Hi, Sometimes when our application is shut down forcibly it is unable to start again with exceptions below. It does not appear that transaction is in progress at the time of shutdown but I can not be sure. I was unable to create test case but our application reproduces this quite consistently (it's very rare that it starts after being terminated). I have attached debug trace file for failed start - not for the shutdown. I tried INFO logging for shutdown (breaking the db) but nothing seemed interesting there, just bunch of selects. Also no error is logged during shutdown or startup. Environment details are - H2 - 1.3.176 - Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, 32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode) - Operating System - Windows 7 (64b, Service Pack 1, version 6.1) - connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE NullPoint
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
I just noticed the version is 1.4.178, not 1.3.x.. I will need to wait for stable release then before I can use the jar Also my jUnit tests failed with inability to create in-memory DB because of missing driver (for jdbc:h2:mem:). not sure whether I'd have to load driver class explicitly for 1.4 but I am falling back to 1.3.x so I will not be investigating that thanks Tono On Thursday, June 5, 2014 10:41:45 AM UTC+2, too wrote: > > Hi, > I tested with the 1.3.178 and I can confirm that it resolved problem. > Tried twice with new jar and problem has not occurred, then tried back with > 1.3.176 and replicated it immediately. With "damaged" DB then tried the new > jar and it recovered just fine. > > I consider this fixed now, thank you! Looking forward for next release and > will use the new jar in the meantime > > thanks > Tono > > On Wednesday, June 4, 2014 8:52:08 PM UTC+2, Thomas Mueller wrote: >> >> Hi, >> >> The latest build is available at: >> http://h2database.com/html/build.html#automated >> >> > Can you point me in some direction as what to look for? >> >> If you don't create temporary tables, then most likely the problem is >> large result sets, as in some cases this will implicitly create temporary >> tables. I found out this week that this was not well tested so far. I found >> a way to better test it, and found a number of issues. I had to fix and >> partially re-write this area, so I believe this will be resolved in the >> next release. >> >> Regards, >> Thomas >> >> >> >> On Tue, Jun 3, 2014 at 10:58 AM, too wrote: >> >>> Hello, >>> I can test the fix for you easily, all I need is h2 jar with fix. >>> >>> Regarding the test I tried all I could think of. Our app is fairly large >>> (15MB jar of classes with lots of framework-ish stuff happening in the >>> background) so it is difficult to point out the scenario. Tried INFO >>> logging to re-execute the same set of queries but that has not replicated >>> the problem. I am also pretty sure we do not create any temporary tables >>> explicitly (also searched code-base for "create memory table"). >>> >>> Can you point me in some direction as what to look for? I mean what >>> would you expect to be happening to create the table? Does H2 create temp >>> tables implicitly? All we do to trigger the problem are select queries >>> (based on the info log I had). >>> >>> thanks >>> Tono >>> >>> On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote: >>> Hi, I could analyze it now. The problem seems to be that creating a temporary table is not committed, and then the temporary table is deleted in another session. I have a fix / workaround for that, but so far no test case. Please tell me if you have a reproducible test case. Regards, Thomas On Tuesday, May 27, 2014, too wrote: > Even though I can reproduce this with our app I fail to create > separate test case to reproduce the problem (i.e. to break the DB). What > I > can do is send you database that H2 fails to open. Perhaps it is not > really > bug during close but not robust enough recovery during startup. Zipped DB > has 10MB and I can share it for you privately if you think that can help > > thanks > Tono > > On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote: > > I have experimented with this a little and here are few notes > >- lock file remains in place - this is consistent with shutdown >hooks not being executed during JVM abort >- size of DB file remains intact during runtime but during process >termination the size rises by approximately 50MB - which contradicts >previous point and it seems there is something executed during abort >- I can replicate problem with 100% success rate using our app but >I fail to create test app to replicate the problem (still have a few > ideas >to try) >- I can replicate the problem with older 1.3.x releases as well as >with latest 1.4.x release (with MV_STORE=FALSE) >- even though I do not think that there are transactions in >progress at the time of termination it is possible there are open > cursors >or something similar - read-related > > I can avoid this problem by running H2 in server mode but that is not > what I want. > > Tono > > On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote: > > Hi, > Sometimes when our application is shut down forcibly it is unable to > start again with exceptions below. It does not appear that transaction is > in progress at the time of shutdown but I can not be sure. I was unable > to > create test case but our application reproduces this quite consistently > (it's very rare that it starts after being terminated). > I have attached debug trace file for failed s
Re: [h2] Exception when opening DB after forced shutdown (1.3.176)
Hi,
You could use version 1.4.178, and append ";mv_store=false" to the database
URL. This will disable the MVStore file format.
> Also my jUnit tests failed with inability to create in-memory DB because
of missing driver (for jdbc:h2:mem:). not sure whether I'd have to load
driver class explicitly for 1.4 but I am falling back to 1.3.x so I will
not be investigating that
No, you don't have to load the driver explicitly for 1.4.x. There is no
change to 1.3.x in this regard. Maybe you need to use
Class.forName("org.h2.Driver"); or solve the classpath problem.
Regards,
Thomas
On Thu, Jun 5, 2014 at 12:59 PM, too wrote:
> I just noticed the version is 1.4.178, not 1.3.x.. I will need to wait for
> stable release then before I can use the jar
>
> Also my jUnit tests failed with inability to create in-memory DB because
> of missing driver (for jdbc:h2:mem:). not sure whether I'd have to load
> driver class explicitly for 1.4 but I am falling back to 1.3.x so I will
> not be investigating that
>
> thanks
> Tono
>
>
> On Thursday, June 5, 2014 10:41:45 AM UTC+2, too wrote:
>>
>> Hi,
>> I tested with the 1.3.178 and I can confirm that it resolved problem.
>> Tried twice with new jar and problem has not occurred, then tried back with
>> 1.3.176 and replicated it immediately. With "damaged" DB then tried the new
>> jar and it recovered just fine.
>>
>> I consider this fixed now, thank you! Looking forward for next release
>> and will use the new jar in the meantime
>>
>> thanks
>> Tono
>>
>> On Wednesday, June 4, 2014 8:52:08 PM UTC+2, Thomas Mueller wrote:
>>>
>>> Hi,
>>>
>>> The latest build is available at: http://h2database.com/
>>> html/build.html#automated
>>>
>>> > Can you point me in some direction as what to look for?
>>>
>>> If you don't create temporary tables, then most likely the problem is
>>> large result sets, as in some cases this will implicitly create temporary
>>> tables. I found out this week that this was not well tested so far. I found
>>> a way to better test it, and found a number of issues. I had to fix and
>>> partially re-write this area, so I believe this will be resolved in the
>>> next release.
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>> On Tue, Jun 3, 2014 at 10:58 AM, too wrote:
>>>
Hello,
I can test the fix for you easily, all I need is h2 jar with fix.
Regarding the test I tried all I could think of. Our app is fairly
large (15MB jar of classes with lots of framework-ish stuff happening in
the background) so it is difficult to point out the scenario. Tried INFO
logging to re-execute the same set of queries but that has not replicated
the problem. I am also pretty sure we do not create any temporary tables
explicitly (also searched code-base for "create memory table").
Can you point me in some direction as what to look for? I mean what
would you expect to be happening to create the table? Does H2 create temp
tables implicitly? All we do to trigger the problem are select queries
(based on the info log I had).
thanks
Tono
On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote:
> Hi,
>
> I could analyze it now. The problem seems to be that creating a
> temporary table is not committed, and then the temporary table is deleted
> in another session. I have a fix / workaround for that, but so far no test
> case. Please tell me if you have a reproducible test case.
>
> Regards,
> Thomas
>
>
>
> On Tuesday, May 27, 2014, too wrote:
>
>> Even though I can reproduce this with our app I fail to create
>> separate test case to reproduce the problem (i.e. to break the DB). What
>> I
>> can do is send you database that H2 fails to open. Perhaps it is not
>> really
>> bug during close but not robust enough recovery during startup. Zipped DB
>> has 10MB and I can share it for you privately if you think that can help
>>
>> thanks
>> Tono
>>
>> On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote:
>>
>> I have experimented with this a little and here are few notes
>>
>>- lock file remains in place - this is consistent with shutdown
>>hooks not being executed during JVM abort
>>- size of DB file remains intact during runtime but during
>>process termination the size rises by approximately 50MB - which
>>contradicts previous point and it seems there is something executed
>> during
>>abort
>>- I can replicate problem with 100% success rate using our app
>>but I fail to create test app to replicate the problem (still have a
>> few
>>ideas to try)
>>- I can replicate the problem with older 1.3.x releases as well
>>as with latest 1.4.x release (with MV_STORE=FALSE)
>>- even though I do not think that there are transactions in
>>progress at the time of termination
