Re: [h2] does LIMIT improve performane
On 2015-01-04 05:14 PM, Adam McMahon wrote: If there is a limit, does the engine stop searching once the LIMIT has been found? Yes. -- 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] setQueryTimeout on a JDBC Statement seems to effect the entire connection not just the Statement object
On 2015-01-02 06:52 PM, Kenton Garner wrote: Is there a way for H2 to implement the setQueryTimeout() method to only effect the current Statement object. Not easily I'm afraid. I think we'd need to change the protocol to include the timeout on every command. Perhaps your connection pool has a hook that you can run after it creates the connection? I know the one I used to use did. -- 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] Script tool puts blocksize option in wrong place in generated SQL.
Hi Thank you very much for the excellent problem report, I have committed a fix. Regards, Noel. -- 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] File corrupted while reading record: 1060 of 43. Possible solution: use the recovery tool [90030-184]
Do you realise that you are using the FILE_LOCK=NO option, which can lead to corruption? http://h2database.com/html/features.html?highlight=FILE_LOCKsearch=file_lock#database_file_locking -- 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] Re: Performance regression in versions starting 1.165 when using BLOB in temporary table
Hi Thanks for your problem report and investigation. I have committed a fix for this. Regards, Noel. -- 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] Script tool without -options adds every line of output to result set
Hi,
Good point! I will fix this for the next release (with a slightly different
patch; I will also remove some of the unused methods).
Regards,
Thomas
On Saturday, January 3, 2015, Ken Jorissen ken.joris...@gmail.com wrote:
With this setup:
$ java -cp ~/data/git/h2-1.3.174/h2/bin/h2-1.3.174.jar org.h2.tools.Shell
-url jdbc:h2:./test -sql create table foo (bar int)
$ java -cp ~/data/git/h2-1.3.174/h2/bin/h2-1.3.174.jar org.h2.tools.Shell
-url jdbc:h2:./test -user sa -password sa -sql insert into foo values
(1)
These two commands do very different things internally:
$ java -cp ~/data/git/h2-1.3.174/h2/bin/h2-1.3.174.jar org.h2.tools.Script
-url jdbc:h2:./test -user sa -password sa -script script.sql
$ java -cp ~/data/git/h2-1.3.174/h2/bin/h2-1.3.174.jar org.h2.tools.Shell
-url jdbc:h2:./test -user sa -password sa -sql SCRIPT TO 'shell.sql'
When using the script tool, it executes the SQL SCRIPT. The query
execution doesn't get the OutputStream and all the data is added to the
result set. For a large database, that can be problematic because a large
temp table can be created. That takes a lot longer (my test case of a 5GB
database dumps in 30 minutes versus about 3 minutes) and temporarily uses a
lot of disk space (30 extra GB versus no extra space when the temp table is
avoided).
When using the shell tool to execute SCRIPT to 'shell.sql', the
OutputStream is set and the insert statements do not go into the result set
leading to no temp table in most cases.
Using any of the -options arguments or just a naked -options on the end
will force Script.java to go through Script.processScript(). That generates
the SQL as SCRIPT TO 'filename.sql', that gets around this as well.
Is there a reason to use the form that just calls SCRIPT? The following
diff unifies the behavior and I don't see a downside:
===
--- src/main/org/h2/tools/Script.java (revision 5922)
+++ src/main/org/h2/tools/Script.java (working copy)
@@ -59,7 +59,7 @@
String user = sa;
String password = ;
String file = backup.sql;
-String options1 = null, options2 = null;
+String options1 = , options2 = ;
for (int i = 0; args != null i args.length; i++) {
String arg = args[i];
if (arg.equals(-url)) {
@@ -98,11 +98,7 @@
showUsage();
throw new SQLException(URL not set);
}
-if (options1 != null) {
-processScript(url, user, password, file, options1, options2);
-} else {
-execute(url, user, password, file);
-}
+processScript(url, user, password, file, options1, options2);
}
private static void processScript(String url, String user, String
password,
The above is against 1.3.174. Other than the default user changing, trunk
looks the same.
I work with a program that is calling org.h2.tools.Script.execute(url,
user, password, fileName). I was working on setting BLOCKSIZE, but now I am
on a tangent trying to figure out why it doesn't seem to be making a giant
temp table. I ran into this when testing things and found the workaround.
More debugging. I'm thinking we should just use the SQL manually instead of
the tool. That way we can set BLOCKSIZE. Any thoughts on that would be
greatly appreciated.
Thanks,
Ken
--
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
javascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com');
.
To post to this group, send email to h2-database@googlegroups.com
javascript:_e(%7B%7D,'cvml','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] .mv.db file size grows large
Hi, I think I found and fixed this problem now. The fix is in the trunk. I also have a test case to reproduce the issue. From the stack trace it's relatively clear it is the same issue. Regards, Thomas On Monday, December 22, 2014, pishen tsai pishe...@gmail.com wrote: Sorry, the exception only happens when closing a connection with a large amount (114508) of MERGE queries executed, and I couldn't post the test case for you. The table only contains three columns as name VARCHAR PRIMARY KEY, df INT, category_counts VARCHAR This is reproducible in both 1.4.183 and 1.4.184. In 1.4.184 I got org.h2.jdbc.JdbcSQLException: General error: java.lang.IllegalStateException: Negative position -1593 [1.4.184/6] [5-184] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) ~[h2-1.4.184.jar:1.4.184] at org.h2.message.DbException.get(DbException.java:168) ~[h2-1.4.184.jar:1.4.184] at org.h2.message.DbException.convert(DbException.java:295) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.db.MVTableEngine$1.uncaughtException(MVTableEngine.java:93) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.MVStore.writeInBackground(MVStore.java:2374) ~[h2-1.4.184.jar:1.4.184] Caused by: java.lang.IllegalStateException: Negative position -1593 [1.4.184/6] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.MVStore.readPageChunkReferences(MVStore.java:1267) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1245) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1249) ~[h2-1.4.184.jar:1.4.184] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1249) ~[h2-1.4.184.jar:1.4.184] I'm falling back to 1.4.182 now and I found that the .mv.db file is no longer that large (around 500M), not sure if I suddenly change anything. Regards, Pishen 2014-12-20 16:11 GMT+08:00 Thomas Mueller thomas.tom.muel...@gmail.com javascript:_e(%7B%7D,'cvml','thomas.tom.muel...@gmail.com');: Hi, Is this exception reproducible with version 1.4.184, with a fresh database? If yes, would it be possible to send me or post a reproducible test case? Regards, Thomas On Wed, Dec 17, 2014 at 5:36 PM, pishen tsai pishe...@gmail.com javascript:_e(%7B%7D,'cvml','pishe...@gmail.com'); wrote: The .mv.db file is not growing that large (now around 200M) even without re-opening this time. But I got an Exception that I have no idea why... org.h2.jdbc.JdbcSQLException: General error: java.lang.IllegalStateException: Negative position -1847 [1.4.183/6] [5-183] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) ~[h2-1.4.183.jar:1.4.183] at org.h2.message.DbException.get(DbException.java:168) ~[h2-1.4.183.jar:1.4.183] at org.h2.message.DbException.convert(DbException.java:295) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.db.MVTableEngine$1.uncaughtException(MVTableEngine.java:93) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.MVStore.writeInBackground(MVStore.java:2369) ~[h2-1.4.183.jar:1.4.183] Caused by: java.lang.IllegalStateException: Negative position -1847 [1.4.183/6] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:768) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.MVStore.readPageChunkReferences(MVStore.java:1262) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1240) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1244) ~[h2-1.4.183.jar:1.4.183] at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1244) ~[h2-1.4.183.jar:1.4.183] Regards, Pishen 2014-12-16 0:13 GMT+08:00 pishen tsai pishe...@gmail.com javascript:_e(%7B%7D,'cvml','pishe...@gmail.com');: Thanks, I will try it in days, and will report the result after that. Regards, Pishen 2014-12-16 0:09 GMT+08:00 Thomas Mueller thomas.tom.muel...@gmail.com javascript:_e(%7B%7D,'cvml','thomas.tom.muel...@gmail.com');: Hi, Could you try again with the latest version of H2? (Please not there is a bug that prevents index usage if you use auto-increment column; but I think you don't use this, so it shouldn't affect you). Regards, Thomas On Mon, Dec 1, 2014 at 12:18 PM, pishen tsai pishe...@gmail.com javascript:_e(%7B%7D,'cvml','pishe...@gmail.com'); wrote: Hi, I have surveyed a bit and found that h2 need to compact the database when the JDBC connection is closed. Hence I tried to close and reopen the connection every 1000~2000 INSERT/UPDATE. Now the size of .mv.db grows much slower, but the size is still larger than 44M, maybe I have to enlarge the shutdown delay for the DB to compact more. May tried that later. Thanks, pishen Thomas
[h2] Attempted to run 1.4.184 overnight and failed with ArrayIndexOutOfBoundsException
Hi, I think I found and fixed this problem now. The fix is in the trunk. Usually, the exception message is different (IllegalStateException instead of ArrayIndexOutOfBoundsException), but from the stack trace it's relatively clear it is the same issue. Regards, Thomas On Saturday, December 27, 2014, Kenton Garner kenton.gar...@gmail.com javascript:_e(%7B%7D,'cvml','kenton.gar...@gmail.com'); wrote: I am not sure what caused this. I have the corrupt database. Do you have any ideas? I will include the stack traces from each of the three application that were accessing the database at the time... #1 - 14 Dec 23 00:01:31:559 ERROR MVStore background writer nio:/opt/cds/dataSyncPlus/data/audit/msgfwd.mv.db - [DataSync+ Recv-00]: h2database: msgfwd:database flush org.h2.message.DbException: General error: java.lang.ArrayIndexOutOfBoundsException [5-184] at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.mvstore.db.MVTableEngine$1.uncaughtException(MVTableEngine.java:93) at org.h2.mvstore.MVStore.writeInBackground(MVStore.java:2374) at org.h2.mvstore.MVStore$BackgroundWriterThread.run(MVStore.java:2560) Caused by: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException [5-184] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) ... 5 more Caused by: java.lang.ArrayIndexOutOfBoundsException - #2 - 14 Dec 23 00:01:30:453 ERROR directory-poller-0 - [DataSync+ Send-02]: h2database: jdbc exception org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException [5-184] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.server.TcpServerThread.sendError(TcpServerThread.java:221) at org.h2.server.TcpServerThread.run(TcpServerThread.java:161) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.ArrayIndexOutOfBoundsException at org.h2.engine.SessionRemote.done(SessionRemote.java:622) at org.h2.command.CommandRemote.executeUpdate(CommandRemote.java:191) at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:130) at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:115) at com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager$3.runTask(FwdMsgQueueManager.java:332) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.runQuery(FwdMsgQueueManager.java:818) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.closeForwardedMessage(FwdMsgQueueManager.java:296) at com.issinc.cds.sbsend.input.poller.MessageForwardDirPollerRenamer$1$1.requestHandled(MessageForwardDirPollerRenamer.java:121) at com.issinc.cds.sbsend.mfwd.proc.MessageForwardMessageRouter.processRequest(MessageForwardMessageRouter.java:106) at com.issinc.cds.sbsend.input.poller.MessageForwardDirPollerRenamer$1.ProcessData(MessageForwardDirPollerRenamer.java:111) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager$4.runTask(FwdMsgQueueManager.java:451) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.runQuery(FwdMsgQueueManager.java:818) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.getMessage(FwdMsgQueueManager.java:419) at com.issinc.cds.sbsend.input.poller.MessageForwardDirPollerRenamer.rename(MessageForwardDirPollerRenamer.java:104) at org.sadun.util.polling.DirectoryPoller.runCycle(DirectoryPoller.java:1171) at org.sadun.util.polling.DirectoryPoller.run(DirectoryPoller.java:964) at com.issinc.cds.poller.CDSDirectoryPoller.run(CDSDirectoryPoller.java:85) 14 Dec 23 00:01:30:458 ERROR directory-poller-0 - [DataSync+ Send-02]: FwdMsgQueueManager: SQLException on [DELETE FROM CDS_FWD_DATA WHERE FILENAME='00-201413555717_58636-ORACLE.GDS2DB_OWNER.0' AND DATE='2014-12-22 23:55:42.531850'] state:[HY000] code:[5] - #3 - 14 Dec 23 00:01:30:181 ERROR directory-poller-0 - [DataSync+ Send-03]: FwdMsgQueueManager: SQLException on [UPDATE CDS_FWD_DATA SET PUBLISH_COUNT=(PUBLISH_COUNT-1) WHERE FILENAME='00-20141223000113236000_60456-ORACLE.GDS2DB_OWNER.0' AND DATE='2014-12-23 00:00:58.638670'] state:[HY000] code:[5] org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: -2635 [5-184] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at
Re: [h2] 1.4 beta creates much bigger database file
Hi, OK, that's nice! There is still quite a lot of room for improvements, and I don't consider this completely fixed, but will not work on it with very high priority any longer. Regards, Thomas On Sunday, December 21, 2014, Steve McLeod steve.mcl...@gmail.com wrote: Hi Thomas, The database file size in 1.4.184 is much, much better than in earlier 1.4.x releases. I've done some trials and these are my findings: 1.3.176: Fully loaded database after shutdown is 317 Mb 1.4.184: Fully loaded database after shutdown is 380 Mb This seems reasonable. On Friday, 19 December 2014 17:15:29 UTC+8, Thomas Mueller wrote: Hi, Version 1.4.184 should produce smaller database files than previous version (1.4.x - 1.4.182), maybe half or a third of the old file size. It would be great to get some real-world results! Regards, Thomas On Tue, May 6, 2014 at 6:24 PM, Thomas Mueller thomas.to...@gmail.com wrote: Hi, Some initial results: you can shrink the database by running shutdown compact or shutdown defrag. Each time this is run, it shrinks a few MB (up to some point, of course). This works, but it's relatively slow. Now the task is to make it faster. There are two ways: shrink it fully to the minimum size, and shrink it incrementally (like now) but faster. I'm working on that now. Regards, Thomas On Tue, May 6, 2014 at 11:39 AM, Steve McLeod steve@gmail.com wrote: Hi Thomas, I've sent you a private email with a link to the new database file, made with H2 1.4.178 Regards, Steve On Monday, 5 May 2014 07:46:16 UTC+2, Thomas Mueller wrote: Hi, The database file should shrink if you run shutdown defrag. The current compact algorithm is quite inefficient, that means the databases file is quite big on average. The highest priority is still to ensure it always works correctly, and when that's done I will work on more efficiently re-using disk space and specially compact the file faster when closing the database. Could you send me the new database file? It would be nice to have a real-world database file to test this. The last file you sent helped a lot, thanks to it I found some problems that completely prevented the file to shrink. Regards, Thomas On Sunday, May 4, 2014, Steve McLeod steve@gmail.com wrote: Hi Thomas, I tested the same large data import with H2 1.4.178, and there is no improvement over H2 1.4.177. Here are the file sizes, in both cases after the app has stopped: H2 1.3.176: pokercopilot.h2.db 301,669,352 bytes H2 1.4.178: pokercopilot.mv.db 1,023,037,440 bytes Let me know what I can do to help. Regards, Steve On Saturday, 19 April 2014 11:44:05 UTC+2, Steve McLeod wrote: Hi Thomas, Great! Glad I could help make your superb product even better. On Friday, 18 April 2014 21:38:27 UTC+2, Thomas Mueller wrote: Hi, Thanks a lot for the database! I know what the problem is now, but I couldn't fix it yet. The database file (pokercopilot2.mv.db) has about 181 MB of live data, the rest (about 78%) is not used. The mechanism to get rid of the unused space is not working as it should for this case (I think the problem is that b-tree nodes are not processed correctly). This will be fixed in the next release. Regards, Thomas On Fri, Apr 18, 2014 at 5:29 PM, Steve McLeod steve@gmail.com wrote: Hi Thomas, I've sent a link to file privately to your email address. Regards, Steve On Friday, 18 April 2014 14:04:37 UTC+2, Thomas Mueller wrote: Hi, Hm, that didn't help much. Could you send me the (compressed) database files please? If it's too big, what is the compressed size of the files? Regards, Thomas On Fri, Apr 18, 2014 at 1:07 PM, Steve McLeod steve@gmail.com wrote: Hi Thomas, Thanks for the suggestion. I tried adding ;retention_time=1000 to the URL, and this resulted in a small improvement. pokercopilot.h2.db 302,018,560 bytes pokercopilot.mv.db 999,120,896 bytes pokercopilot.mv.db with RETENTION_TIME=1000: 811,728,896 bytes These numbers all reflect a loading of data in a newly created database that consisted of roughly 2,400,000 INSERTS and UPDATES with plenty of SELECTS and almost no DELETES. After the loading was complete, I let the application keep running with the database open for a few minutes, then close the application and therefore the database. Here is the full JDBC url I'm using: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware. pokercopilot/database/pokercopilot;DATABASE_EVENT_LISTENER='co m.barbarysoftware.pokercopilot.database.DatabaseListener';COMPRESS_ LOB=DEFLATE;CACHE_SIZE=65536;RETENTION_TIME=1000 Let me know if there is anything else I can do to help diagnose this. Regards, Steve On Thursday, 17 April 2014 17:15:50 UTC+2, Thomas Muel -- You received this message because you are subscribed to the Google Groups H2 Database group. To unsubscribe from this group and stop
Re: [h2] Attempted to run 1.4.184 overnight and failed with ArrayIndexOutOfBoundsException
Thomas, 1.) Thanks I will see if I can check that version out. 2.) I had a another problem recently that did throw an IllegalStateException. I will attach the stack here, to see if it is the same issue. 3.) This second exception that i am referring to highlighted another more serious issue for me having to do with transaction / commit / rollback. I have my connection set to AutoCommit=FALSE. In this test I log the result of getAutoCommit() from the connection returned from my connection pool to insure that it is still set to FALSE. I perform one update and one select before committing the transaction ( conn.commit(); ) The IllegalStateException was thrown on the commit() call. Because I got an exception thrown I attempt to rollback() the connection and then retry the commands. The problem is that the database committed the UPDATE even though the commit() call failed and I attempted a rollback(). Subsequently, I Updated the row twice - which in this case causes unrecoverable problems because the update decrements a counter one too many times. So my question here would be why was the transaction committed when an exception was thrown and what could I possibly do to prevent this? Exception stack... 15 Jan 02 18:21:36:599 WARN directory-poller-0 - [DataSync+ Send-03]: FwdMsgQueueManager: KENT runQuery - autocommit: [false] 15 Jan 02 18:21:36:894 WARN directory-poller-0 - [DataSync+ Send-03]: FwdMsgQueueManager: KENT DB closeForwardMessage(a): [UPDATE CDS_FWD_DATA SET PUBLISH_COUNT=(PUBLISH_COUNT-1) WHERE FILENAME='00-20150102182059026000_55430-ORACLE.GDS2DB_OWNER.0' AND DATE='2015-01-02 18:20:39.723501'] rows updated:[1] 15 Jan 02 18:21:36:894 WARN directory-poller-0 - [DataSync+ Send-03]: FwdMsgQueueManager: KENT DB closeForwardMessage(b): [SELECT PUBLISH_COUNT FROM CDS_FWD_DATA WHERE FILENAME='00-20150102182059026000_55430-ORACLE.GDS2DB_OWNER.0' AND DATE='2015-01-02 18:20:39.723501'] 15 Jan 02 18:21:36:894 WARN directory-poller-0 - [DataSync+ Send-03]: FwdMsgQueueManager: KENT DB closeForwardMessage(b1): counter: [1] -- is it = 0 15 Jan 02 18:21:37:769 ERROR directory-poller-0 - [DataSync+ Send-03]: h2database: jdbc exception org.h2.jdbc.JdbcSQLException: General error: java.lang.IllegalStateException: File corrupted in chunk 373738, expected page length = 12288, got 1677721856 [1.4.184/6]; SQL statement: COMMIT [5-184] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.command.Command.executeUpdate(Command.java:262) at org.h2.server.TcpServerThread.process(TcpServerThread.java:345) at org.h2.server.TcpServerThread.run(TcpServerThread.java:159) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalStateException: File corrupted in chunk 373738, expected page length = 12288, got 1677721856 [1.4.184/6] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773) at org.h2.mvstore.Page$PageChildren.read(Page.java:1035) at org.h2.mvstore.MVStore.readPageChunkReferences(MVStore.java:1272) at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1245) at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1249) at org.h2.mvstore.MVStore.collectReferencedChunks(MVStore.java:1232) at org.h2.mvstore.MVStore.freeUnusedChunks(MVStore.java:1191) at org.h2.mvstore.MVStore.compactRewrite(MVStore.java:1793) at org.h2.mvstore.MVStore.compact(MVStore.java:1678) at org.h2.mvstore.db.MVTableEngine$Store.flush(MVTableEngine.java:198) at org.h2.engine.Database.flush(Database.java:2019) at org.h2.engine.Session.endTransaction(Session.java:549) at org.h2.engine.Session.commit(Session.java:536) at org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:46) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) ... 3 more at org.h2.engine.SessionRemote.done(SessionRemote.java:622) at org.h2.command.CommandRemote.executeUpdate(CommandRemote.java:191) at org.h2.jdbc.JdbcConnection.commit(JdbcConnection.java:468) at com.zaxxer.hikari.proxy.ConnectionProxy.commit(ConnectionProxy.java:298) at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.commit(ConnectionJavassistProxy.java) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.runQuery(FwdMsgQueueManager.java:867) at com.issinc.cds.sb.mfwd.impl.FwdMsgQueueManager.closeForwardedMessage(FwdMsgQueueManager.java:332) at com.issinc.cds.sbsend.input.poller.MessageForwardDirPollerRenamer$1$1.requestHandled(MessageForwardDirPollerRenamer.java:125) at
