Hi,
I'm using version 1.4.193.
What do you mean by create a test case? I'm not sure I understand.
By the way I ran several test on linux rather than windows but on the same
computer and it went better.
Thx,
Nicolas
Le dimanche 12 février 2017 14:00:51 UTC+1, Thomas Mueller Graf a écrit :
>
>
Hi,
collectReferencedChunks used to be a problem in the past, but recent
version of H2 should be better. Which version do you use? If the latest
version, could you create a simple test case?
Regards,
Thomas
On Fri, Jan 27, 2017 at 12:48 PM, Noel Grandin
wrote:
> yeah,
Thanks, indeed it was easy, here the stack which is taking a few seconds :
MainH2DataArchiAlone [Java Application]
h2.MainH2DataArchiAlone at localhost:51761
Thread [pool-1-thread-1] (Suspended)
owns: Object (id=50)
owns: MVStore (id=51)
owns: TransactionStore (id=52)
owns: Database
What I would do is set the breakpoint to stop all threads in the VM.
Then I would see what my thread is blocked on - probably the main database lock
object.
Then I would see what thread is holding that lock, and print out that stack
trace (or take a screenshot).
In Eclipse this is fairly
First thank you for the help.
I couldn't print stack trace of what's happening in H2. When I stop at the
right point with a debugger and try to print the stack trace it only show
me what's happening in my thread not in H2. Could you tell me more
precisely what I can do to in order to see
Hmm, that is being less useful than I thought, because that's all on the
background thread, but what we want to know is what the current thread is
up to.
I regularly run large db's (several G) but I never do inserts of that size,
so I'm not sure what is causing that.
Could you maybe run it under
Here is what the profiler gives me :
Profiler: top 3 stack trace(s) of of 59010 ms of 29386 thread dumps:
29222/29386 (99%):
at org.h2.store.fs.FileNio.read(FilePathNio.java:74)
at org.h2.mvstore.DataUtils.readFully(DataUtils.java:421)
at org.h2.mvstore.FileStore.readFully(FileStore.java:98)
at