Re: [h2] Re: File corruption with nioMemLZF

2017-04-04 Thread Andrey Belyaev
I faced the same issue today. On Monday, January 23, 2017 at 4:16:32 PM UTC+5, Anatolii K wrote: > > One more problem :( : > > It happens rarely and unpredictable > > Caused by: java.lang.ClassCastException: org.h2.value.ValueNull cannot be > cast to org.h2.value.ValueArray > at >

Re: [h2] Re: File corruption with nioMemLZF

2017-01-23 Thread Anatolii K
One more problem :( : It happens rarely and unpredictable Caused by: java.lang.ClassCastException: org.h2.value.ValueNull cannot be cast to org.h2.value.ValueArray at org.h2.mvstore.db.MVPrimaryIndex$MVStoreCursor.get(MVPrimaryIndex.java:402) at

Re: [h2] Re: File corruption with nioMemLZF

2017-01-23 Thread Noel Grandin
I have committed a cache-sizing feature for this filesystem -- 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

Re: [h2] Re: File corruption with nioMemLZF

2017-01-22 Thread Noel Grandin
On 2017/01/23 9:42 AM, Anatolii K wrote: Thank you Noel for the explanation I think it would be very useful to be able to control the cach size. And I would like to be able to do it dynamically, without database restart Yeah, sorry, the "dynamic without restart" part is not going to

Re: [h2] Re: File corruption with nioMemLZF

2017-01-22 Thread Noel Grandin
Firstly note that this test generates fairly widely varying results, so you need to run it a couple of times and average the output. That said, this performance here is completely dependant on the CACHE_SIZE constant in FileNioMemData. A value of anything > approx 80 produces decent performance.

Re: [h2] Re: File corruption with nioMemLZF

2017-01-21 Thread Anatolii K
I found one more scenario where compressed database is 30 times slower - see attachment But now it's not related to synchronization because the test is single threaded -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this

Re: [h2] Re: File corruption with nioMemLZF

2017-01-20 Thread Noel Grandin
Ah that was silly, forgot to hit the sync button.Done now.​ -- 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

Re: [h2] Re: File corruption with nioMemLZF

2017-01-20 Thread Anatolii K
Have you aready commited at github? I don't see it On Friday, January 20, 2017 at 2:26:20 PM UTC, Noel Grandin wrote: > > I have pushed a fix for this. > > On 2017/01/20 2:23 PM, Anatolii K wrote: > > Please see attached. > > > > At my notebook the test takes 0.9s without compression and 50s

Re: [h2] Re: File corruption with nioMemLZF

2017-01-20 Thread Noel Grandin
I have pushed a fix for this. On 2017/01/20 2:23 PM, Anatolii K wrote: Please see attached. At my notebook the test takes 0.9s without compression and 50s with compression -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from

Re: [h2] Re: File corruption with nioMemLZF

2017-01-20 Thread Anatolii K
Please see attached. At my notebook the test takes 0.9s without compression and 50s with compression On Thursday, January 19, 2017 at 5:51:36 PM UTC, Noel Grandin wrote: > > Can you post your performance test code? > On Thu, 19 Jan 2017 at 18:36, Anatolii K > wrote: >

Re: [h2] Re: File corruption with nioMemLZF

2017-01-19 Thread Noel Grandin
Can you post your performance test code? On Thu, 19 Jan 2017 at 18:36, Anatolii K wrote: > Sorry to say so, but performance dropped dramatically. > Previously compressed storage was just a bit slower than uncompressed. > But now it become almost 100 times slower! > > > > On

Re: [h2] Re: File corruption with nioMemLZF

2017-01-19 Thread Anatolii K
Sorry to say so, but performance dropped dramatically. Previously compressed storage was just a bit slower than uncompressed. But now it become almost 100 times slower! On Thursday, January 19, 2017 at 1:32:49 PM UTC, Noel Grandin wrote: > > I have pushed a fix for this, it now survives your

Re: [h2] Re: File corruption with nioMemLZF

2017-01-19 Thread Noel Grandin
I have pushed a fix for this, it now survives your test. I had to simplify the current code and just synchronize the methods, which means it may lose some performance. If this is a problem for you, I'm sorry, but you'll have to come up with some patches yourself. -- You received this message

[h2] Re: File corruption with nioMemLZF

2017-01-19 Thread Anatolii K
Sorry for bothering you, but could you please look at it -- 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