Liveness problem with read operation

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Liveness problem with read operation

Sergio Bossa
Hi,

I'm running into a subtle problem with HSQLDB (version 2.2.8)
apparently getting into a kind of liveness problem, where a read
operation running indefinitely prevents all other operations to
continue.

This is the thread dump of the read operation:

"Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
   java.lang.Thread.State: RUNNABLE
        at java.io.RandomAccessFile.readBytes(Native Method)
        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
        at org.hsqldb.index.IndexAVL.last(Unknown Source)
        at org.hsqldb.index.IndexAVL.last(Unknown Source)
        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown Source)
        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown Source)
        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown Source)
        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
        at org.hsqldb.StatementQuery.getResult(Unknown Source)
        at org.hsqldb.StatementDMQL.execute(Unknown Source)
        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
        at org.hsqldb.Session.execute(Unknown Source)
        - locked <0x54692380> (a org.hsqldb.Session)
        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)
        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown Source)
        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)

And this is the dump of all other operations:

"14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
condition [0x4e875000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x8c2912a0> (a
java.util.concurrent.CountDownLatch$Sync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
        at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown Source)
        at org.hsqldb.Session.execute(Unknown Source)
        - locked <0x54692580> (a org.hsqldb.Session)
        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown Source)
        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)

If I run multiple dumps, the read operation stays around the same
lines of code - that is, line changes between dumps but always stay
the same cyclically, as if it were in a loop - while other operations
are all stuck waiting for the latch.

Has anyone experienced such a thing?

Thanks,

Sergio B.

--
Sergio Bossa
http://www.linkedin.com/in/sergiob

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Fred Toussi-2
If the database is running under the default LOCKS mode (2 phased
locking), tables are locked for read until commit. Any write will have
to wait, but reads can go ahead.

Fred

On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:

> Hi,
>
> I'm running into a subtle problem with HSQLDB (version 2.2.8)
> apparently getting into a kind of liveness problem, where a read
> operation running indefinitely prevents all other operations to
> continue.
>
> This is the thread dump of the read operation:
>
> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
>    java.lang.Thread.State: RUNNABLE
>         at java.io.RandomAccessFile.readBytes(Native Method)
>         at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
>         at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
>         at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
>         at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
>         at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
>         at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
>         at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
>         at org.hsqldb.persist.DataFileCache.get(Unknown Source)
>         at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
>         at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
>         at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
>         at org.hsqldb.index.IndexAVL.last(Unknown Source)
>         at org.hsqldb.index.IndexAVL.last(Unknown Source)
>         at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
>         Source)
>         at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
>         Source)
>         at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
>         Source)
>         at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
>         at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
>         at org.hsqldb.QuerySpecification.getResult(Unknown Source)
>         at org.hsqldb.StatementQuery.getResult(Unknown Source)
>         at org.hsqldb.StatementDMQL.execute(Unknown Source)
>         at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>         at org.hsqldb.Session.execute(Unknown Source)
>         - locked <0x54692380> (a org.hsqldb.Session)
>         at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
>         Source)
>         at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
>         Source)
>         - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>
> And this is the dump of all other operations:
>
> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
> condition [0x4e875000]
>    java.lang.Thread.State: WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x8c2912a0> (a
> java.util.concurrent.CountDownLatch$Sync)
>         at
>         java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
>         at
>         java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>         at
>         java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>         at
>         java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>         at
>         java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
>         at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
>         at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>         at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
>         Source)
>         at org.hsqldb.Session.execute(Unknown Source)
>         - locked <0x54692580> (a org.hsqldb.Session)
>         at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
>         Source)
>         - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>
> If I run multiple dumps, the read operation stays around the same
> lines of code - that is, line changes between dumps but always stay
> the same cyclically, as if it were in a loop - while other operations
> are all stuck waiting for the latch.
>
> Has anyone experienced such a thing?
>
> Thanks,
>
> Sergio B.
>
> --
> Sergio Bossa
> http://www.linkedin.com/in/sergiob
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Sergio Bossa
Fred, it is running with MVCC, and btw, the blocking operation is a read one, and other reads are blocked too.

Sergio Bossa
Sent by iPhone

Il giorno 04/apr/2012, alle ore 23:11, Fred Toussi <[hidden email]> ha scritto:

> If the database is running under the default LOCKS mode (2 phased
> locking), tables are locked for read until commit. Any write will have
> to wait, but reads can go ahead.
>
> Fred
>
> On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:
>> Hi,
>>
>> I'm running into a subtle problem with HSQLDB (version 2.2.8)
>> apparently getting into a kind of liveness problem, where a read
>> operation running indefinitely prevents all other operations to
>> continue.
>>
>> This is the thread dump of the read operation:
>>
>> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
>>   java.lang.Thread.State: RUNNABLE
>>        at java.io.RandomAccessFile.readBytes(Native Method)
>>        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
>>        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
>>        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
>>        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
>>        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
>>        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
>>        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
>>        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
>>        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
>>        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
>>        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
>>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>>        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
>>        Source)
>>        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
>>        Source)
>>        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
>>        Source)
>>        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
>>        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
>>        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
>>        at org.hsqldb.StatementQuery.getResult(Unknown Source)
>>        at org.hsqldb.StatementDMQL.execute(Unknown Source)
>>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>        at org.hsqldb.Session.execute(Unknown Source)
>>        - locked <0x54692380> (a org.hsqldb.Session)
>>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
>>        Source)
>>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
>>        Source)
>>        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>>
>> And this is the dump of all other operations:
>>
>> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
>> condition [0x4e875000]
>>   java.lang.Thread.State: WAITING (parking)
>>        at sun.misc.Unsafe.park(Native Method)
>>        - parking to wait for  <0x8c2912a0> (a
>> java.util.concurrent.CountDownLatch$Sync)
>>        at
>>        java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
>>        at
>>        java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>>        at
>>        java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>>        at
>>        java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>>        at
>>        java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
>>        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
>>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
>>        Source)
>>        at org.hsqldb.Session.execute(Unknown Source)
>>        - locked <0x54692580> (a org.hsqldb.Session)
>>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
>>        Source)
>>        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>>
>> If I run multiple dumps, the read operation stays around the same
>> lines of code - that is, line changes between dumps but always stay
>> the same cyclically, as if it were in a loop - while other operations
>> are all stuck waiting for the latch.
>>
>> Has anyone experienced such a thing?
>>
>> Thanks,
>>
>> Sergio B.
>>
>> --
>> Sergio Bossa
>> http://www.linkedin.com/in/sergiob
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Hsqldb-user mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Fred Toussi-2
There are no read locks with MVCC. There might be something wrong with
this particular database. You can follow this up on the bug tracker and
provide more information.

Fred

On Wed, Apr 4, 2012, at 23:19, Sergio Bossa wrote:

> Fred, it is running with MVCC, and btw, the blocking operation is a read
> one, and other reads are blocked too.
>
> Sergio Bossa
> Sent by iPhone
>
> Il giorno 04/apr/2012, alle ore 23:11, Fred Toussi
> <[hidden email]> ha scritto:
>
> > If the database is running under the default LOCKS mode (2 phased
> > locking), tables are locked for read until commit. Any write will have
> > to wait, but reads can go ahead.
> >
> > Fred
> >
> > On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:
> >> Hi,
> >>
> >> I'm running into a subtle problem with HSQLDB (version 2.2.8)
> >> apparently getting into a kind of liveness problem, where a read
> >> operation running indefinitely prevents all other operations to
> >> continue.
> >>
> >> This is the thread dump of the read operation:
> >>
> >> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
> >>   java.lang.Thread.State: RUNNABLE
> >>        at java.io.RandomAccessFile.readBytes(Native Method)
> >>        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
> >>        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
> >>        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
> >>        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
> >>        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
> >>        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
> >>        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
> >>        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
> >>        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
> >>        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
> >>        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
> >>        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
> >>        Source)
> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
> >>        Source)
> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
> >>        Source)
> >>        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
> >>        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
> >>        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
> >>        at org.hsqldb.StatementQuery.getResult(Unknown Source)
> >>        at org.hsqldb.StatementDMQL.execute(Unknown Source)
> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
> >>        at org.hsqldb.Session.execute(Unknown Source)
> >>        - locked <0x54692380> (a org.hsqldb.Session)
> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
> >>        Source)
> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
> >>        Source)
> >>        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
> >>
> >> And this is the dump of all other operations:
> >>
> >> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
> >> condition [0x4e875000]
> >>   java.lang.Thread.State: WAITING (parking)
> >>        at sun.misc.Unsafe.park(Native Method)
> >>        - parking to wait for  <0x8c2912a0> (a
> >> java.util.concurrent.CountDownLatch$Sync)
> >>        at
> >>        java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> >>        at
> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> >>        at
> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> >>        at
> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> >>        at
> >>        java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> >>        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
> >>        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
> >>        Source)
> >>        at org.hsqldb.Session.execute(Unknown Source)
> >>        - locked <0x54692580> (a org.hsqldb.Session)
> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
> >>        Source)
> >>        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
> >>
> >> If I run multiple dumps, the read operation stays around the same
> >> lines of code - that is, line changes between dumps but always stay
> >> the same cyclically, as if it were in a loop - while other operations
> >> are all stuck waiting for the latch.
> >>
> >> Has anyone experienced such a thing?
> >>
> >> Thanks,
> >>
> >> Sergio B.
> >>
> >> --
> >> Sergio Bossa
> >> http://www.linkedin.com/in/sergiob
> >>
> >> ------------------------------------------------------------------------------
> >> Better than sec? Nothing is better than sec when it comes to
> >> monitoring Big Data applications. Try Boundary one-second
> >> resolution app monitoring today. Free.
> >> http://p.sf.net/sfu/Boundary-dev2dev
> >> _______________________________________________
> >> Hsqldb-user mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
> >
> > ------------------------------------------------------------------------------
> > Better than sec? Nothing is better than sec when it comes to
> > monitoring Big Data applications. Try Boundary one-second
> > resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> > Hsqldb-user mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Sergio Bossa
Hi Fred,

I can certainly open an issue about that and followup on the tracker,
as this problem keeps happening after a few hours of operations,
forcing application restart.
Which other information do you need?

Thanks,

Sergio B.

On Wed, Apr 4, 2012 at 11:36 PM, Fred Toussi
<[hidden email]> wrote:

> There are no read locks with MVCC. There might be something wrong with
> this particular database. You can follow this up on the bug tracker and
> provide more information.
>
> Fred
>
> On Wed, Apr 4, 2012, at 23:19, Sergio Bossa wrote:
>> Fred, it is running with MVCC, and btw, the blocking operation is a read
>> one, and other reads are blocked too.
>>
>> Sergio Bossa
>> Sent by iPhone
>>
>> Il giorno 04/apr/2012, alle ore 23:11, Fred Toussi
>> <[hidden email]> ha scritto:
>>
>> > If the database is running under the default LOCKS mode (2 phased
>> > locking), tables are locked for read until commit. Any write will have
>> > to wait, but reads can go ahead.
>> >
>> > Fred
>> >
>> > On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:
>> >> Hi,
>> >>
>> >> I'm running into a subtle problem with HSQLDB (version 2.2.8)
>> >> apparently getting into a kind of liveness problem, where a read
>> >> operation running indefinitely prevents all other operations to
>> >> continue.
>> >>
>> >> This is the thread dump of the read operation:
>> >>
>> >> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
>> >>   java.lang.Thread.State: RUNNABLE
>> >>        at java.io.RandomAccessFile.readBytes(Native Method)
>> >>        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
>> >>        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
>> >>        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
>> >>        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
>> >>        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
>> >>        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
>> >>        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
>> >>        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
>> >>        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
>> >>        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
>> >>        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
>> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>> >>        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
>> >>        Source)
>> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
>> >>        Source)
>> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
>> >>        Source)
>> >>        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
>> >>        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
>> >>        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
>> >>        at org.hsqldb.StatementQuery.getResult(Unknown Source)
>> >>        at org.hsqldb.StatementDMQL.execute(Unknown Source)
>> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>> >>        at org.hsqldb.Session.execute(Unknown Source)
>> >>        - locked <0x54692380> (a org.hsqldb.Session)
>> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
>> >>        Source)
>> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
>> >>        Source)
>> >>        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>> >>
>> >> And this is the dump of all other operations:
>> >>
>> >> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
>> >> condition [0x4e875000]
>> >>   java.lang.Thread.State: WAITING (parking)
>> >>        at sun.misc.Unsafe.park(Native Method)
>> >>        - parking to wait for  <0x8c2912a0> (a
>> >> java.util.concurrent.CountDownLatch$Sync)
>> >>        at
>> >>        java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
>> >>        at
>> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>> >>        at
>> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>> >>        at
>> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>> >>        at
>> >>        java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
>> >>        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
>> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>> >>        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
>> >>        Source)
>> >>        at org.hsqldb.Session.execute(Unknown Source)
>> >>        - locked <0x54692580> (a org.hsqldb.Session)
>> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
>> >>        Source)
>> >>        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>> >>
>> >> If I run multiple dumps, the read operation stays around the same
>> >> lines of code - that is, line changes between dumps but always stay
>> >> the same cyclically, as if it were in a loop - while other operations
>> >> are all stuck waiting for the latch.
>> >>
>> >> Has anyone experienced such a thing?
>> >>
>> >> Thanks,
>> >>
>> >> Sergio B.
>> >>
>> >> --
>> >> Sergio Bossa
>> >> http://www.linkedin.com/in/sergiob
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Better than sec? Nothing is better than sec when it comes to
>> >> monitoring Big Data applications. Try Boundary one-second
>> >> resolution app monitoring today. Free.
>> >> http://p.sf.net/sfu/Boundary-dev2dev
>> >> _______________________________________________
>> >> Hsqldb-user mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>> >
>> > ------------------------------------------------------------------------------
>> > Better than sec? Nothing is better than sec when it comes to
>> > monitoring Big Data applications. Try Boundary one-second
>> > resolution app monitoring today. Free.
>> > http://p.sf.net/sfu/Boundary-dev2dev
>> > _______________________________________________
>> > Hsqldb-user mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Hsqldb-user mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user



--
Sergio Bossa
http://www.linkedin.com/in/sergiob

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Fred Toussi-2
As much information as possible. List of files, any error reported in
the .app.log file (you should enable this), the query and its expected
execution time, etc.

Fred

On Thu, Apr 5, 2012, at 17:02, Sergio Bossa wrote:

> Hi Fred,
>
> I can certainly open an issue about that and followup on the tracker,
> as this problem keeps happening after a few hours of operations,
> forcing application restart.
> Which other information do you need?
>
> Thanks,
>
> Sergio B.
>
> On Wed, Apr 4, 2012 at 11:36 PM, Fred Toussi
> <[hidden email]> wrote:
> > There are no read locks with MVCC. There might be something wrong with
> > this particular database. You can follow this up on the bug tracker and
> > provide more information.
> >
> > Fred
> >
> > On Wed, Apr 4, 2012, at 23:19, Sergio Bossa wrote:
> >> Fred, it is running with MVCC, and btw, the blocking operation is a read
> >> one, and other reads are blocked too.
> >>
> >> Sergio Bossa
> >> Sent by iPhone
> >>
> >> Il giorno 04/apr/2012, alle ore 23:11, Fred Toussi
> >> <[hidden email]> ha scritto:
> >>
> >> > If the database is running under the default LOCKS mode (2 phased
> >> > locking), tables are locked for read until commit. Any write will have
> >> > to wait, but reads can go ahead.
> >> >
> >> > Fred
> >> >
> >> > On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:
> >> >> Hi,
> >> >>
> >> >> I'm running into a subtle problem with HSQLDB (version 2.2.8)
> >> >> apparently getting into a kind of liveness problem, where a read
> >> >> operation running indefinitely prevents all other operations to
> >> >> continue.
> >> >>
> >> >> This is the thread dump of the read operation:
> >> >>
> >> >> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
> >> >>   java.lang.Thread.State: RUNNABLE
> >> >>        at java.io.RandomAccessFile.readBytes(Native Method)
> >> >>        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
> >> >>        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
> >> >>        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
> >> >>        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
> >> >>        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
> >> >>        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
> >> >>        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
> >> >>        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
> >> >>        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
> >> >>        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
> >> >>        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
> >> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
> >> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
> >> >>        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
> >> >>        Source)
> >> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
> >> >>        Source)
> >> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
> >> >>        Source)
> >> >>        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
> >> >>        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
> >> >>        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
> >> >>        at org.hsqldb.StatementQuery.getResult(Unknown Source)
> >> >>        at org.hsqldb.StatementDMQL.execute(Unknown Source)
> >> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
> >> >>        at org.hsqldb.Session.execute(Unknown Source)
> >> >>        - locked <0x54692380> (a org.hsqldb.Session)
> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
> >> >>        Source)
> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
> >> >>        Source)
> >> >>        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
> >> >>
> >> >> And this is the dump of all other operations:
> >> >>
> >> >> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
> >> >> condition [0x4e875000]
> >> >>   java.lang.Thread.State: WAITING (parking)
> >> >>        at sun.misc.Unsafe.park(Native Method)
> >> >>        - parking to wait for  <0x8c2912a0> (a
> >> >> java.util.concurrent.CountDownLatch$Sync)
> >> >>        at
> >> >>        java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> >> >>        at
> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> >> >>        at
> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> >> >>        at
> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> >> >>        at
> >> >>        java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> >> >>        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
> >> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
> >> >>        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
> >> >>        Source)
> >> >>        at org.hsqldb.Session.execute(Unknown Source)
> >> >>        - locked <0x54692580> (a org.hsqldb.Session)
> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
> >> >>        Source)
> >> >>        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
> >> >>
> >> >> If I run multiple dumps, the read operation stays around the same
> >> >> lines of code - that is, line changes between dumps but always stay
> >> >> the same cyclically, as if it were in a loop - while other operations
> >> >> are all stuck waiting for the latch.
> >> >>
> >> >> Has anyone experienced such a thing?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Sergio B.
> >> >>
> >> >> --
> >> >> Sergio Bossa
> >> >> http://www.linkedin.com/in/sergiob
> >> >>
> >> >> ------------------------------------------------------------------------------
> >> >> Better than sec? Nothing is better than sec when it comes to
> >> >> monitoring Big Data applications. Try Boundary one-second
> >> >> resolution app monitoring today. Free.
> >> >> http://p.sf.net/sfu/Boundary-dev2dev
> >> >> _______________________________________________
> >> >> Hsqldb-user mailing list
> >> >> [hidden email]
> >> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Better than sec? Nothing is better than sec when it comes to
> >> > monitoring Big Data applications. Try Boundary one-second
> >> > resolution app monitoring today. Free.
> >> > http://p.sf.net/sfu/Boundary-dev2dev
> >> > _______________________________________________
> >> > Hsqldb-user mailing list
> >> > [hidden email]
> >> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
> >>
> >> ------------------------------------------------------------------------------
> >> Better than sec? Nothing is better than sec when it comes to
> >> monitoring Big Data applications. Try Boundary one-second
> >> resolution app monitoring today. Free.
> >> http://p.sf.net/sfu/Boundary-dev2dev
> >> _______________________________________________
> >> Hsqldb-user mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
> >
> > ------------------------------------------------------------------------------
> > Better than sec? Nothing is better than sec when it comes to
> > monitoring Big Data applications. Try Boundary one-second
> > resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> > Hsqldb-user mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>
>
>
> --
> Sergio Bossa
> http://www.linkedin.com/in/sergiob
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user
Reply | Threaded
Open this post in threaded view
|

Re: Liveness problem with read operation

Sergio Bossa
Hi Fred,

sorry for this late response.

I tracked down the (very very) slow query to an indexing problem, so
no bug there.
Thanks for the assistance,
Cheers,

Sergio B.

On Thu, Apr 5, 2012 at 6:08 PM, Fred Toussi <[hidden email]> wrote:

> As much information as possible. List of files, any error reported in
> the .app.log file (you should enable this), the query and its expected
> execution time, etc.
>
> Fred
>
> On Thu, Apr 5, 2012, at 17:02, Sergio Bossa wrote:
>> Hi Fred,
>>
>> I can certainly open an issue about that and followup on the tracker,
>> as this problem keeps happening after a few hours of operations,
>> forcing application restart.
>> Which other information do you need?
>>
>> Thanks,
>>
>> Sergio B.
>>
>> On Wed, Apr 4, 2012 at 11:36 PM, Fred Toussi
>> <[hidden email]> wrote:
>> > There are no read locks with MVCC. There might be something wrong with
>> > this particular database. You can follow this up on the bug tracker and
>> > provide more information.
>> >
>> > Fred
>> >
>> > On Wed, Apr 4, 2012, at 23:19, Sergio Bossa wrote:
>> >> Fred, it is running with MVCC, and btw, the blocking operation is a read
>> >> one, and other reads are blocked too.
>> >>
>> >> Sergio Bossa
>> >> Sent by iPhone
>> >>
>> >> Il giorno 04/apr/2012, alle ore 23:11, Fred Toussi
>> >> <[hidden email]> ha scritto:
>> >>
>> >> > If the database is running under the default LOCKS mode (2 phased
>> >> > locking), tables are locked for read until commit. Any write will have
>> >> > to wait, but reads can go ahead.
>> >> >
>> >> > Fred
>> >> >
>> >> > On Wed, Apr 4, 2012, at 19:13, Sergio Bossa wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I'm running into a subtle problem with HSQLDB (version 2.2.8)
>> >> >> apparently getting into a kind of liveness problem, where a read
>> >> >> operation running indefinitely prevents all other operations to
>> >> >> continue.
>> >> >>
>> >> >> This is the thread dump of the read operation:
>> >> >>
>> >> >> "Thread-11" daemon prio=10 tid=0x0a1db800 nid=0x96e runnable [0x4e8c7000]
>> >> >>   java.lang.Thread.State: RUNNABLE
>> >> >>        at java.io.RandomAccessFile.readBytes(Native Method)
>> >> >>        at java.io.RandomAccessFile.read(RandomAccessFile.java:338)
>> >> >>        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397)
>> >> >>        at org.hsqldb.persist.ScaledRAFile.readIntoBuffer(Unknown Source)
>> >> >>        at org.hsqldb.persist.ScaledRAFile.read(Unknown Source)
>> >> >>        at org.hsqldb.persist.ScaledRAFile.readInt(Unknown Source)
>> >> >>        at org.hsqldb.persist.DataFileCache.readObject(Unknown Source)
>> >> >>        at org.hsqldb.persist.DataFileCache.getFromFile(Unknown Source)
>> >> >>        at org.hsqldb.persist.DataFileCache.get(Unknown Source)
>> >> >>        at org.hsqldb.persist.RowStoreAVLDisk.get(Unknown Source)
>> >> >>        at org.hsqldb.index.NodeAVLDisk.findNode(Unknown Source)
>> >> >>        at org.hsqldb.index.NodeAVLDisk.getLeft(Unknown Source)
>> >> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>> >> >>        at org.hsqldb.index.IndexAVL.last(Unknown Source)
>> >> >>        at org.hsqldb.index.IndexAVL$IndexRowIterator.getNextRow(Unknown
>> >> >>        Source)
>> >> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.findNext(Unknown
>> >> >>        Source)
>> >> >>        at org.hsqldb.RangeVariable$RangeIteratorMain.next(Unknown
>> >> >>        Source)
>> >> >>        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
>> >> >>        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
>> >> >>        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
>> >> >>        at org.hsqldb.StatementQuery.getResult(Unknown Source)
>> >> >>        at org.hsqldb.StatementDMQL.execute(Unknown Source)
>> >> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>> >> >>        at org.hsqldb.Session.execute(Unknown Source)
>> >> >>        - locked <0x54692380> (a org.hsqldb.Session)
>> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown
>> >> >>        Source)
>> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeQuery(Unknown
>> >> >>        Source)
>> >> >>        - locked <0x88160820> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>> >> >>
>> >> >> And this is the dump of all other operations:
>> >> >>
>> >> >> "14713721@qtp-8762992-9" prio=10 tid=0x09d22800 nid=0x2465 waiting on
>> >> >> condition [0x4e875000]
>> >> >>   java.lang.Thread.State: WAITING (parking)
>> >> >>        at sun.misc.Unsafe.park(Native Method)
>> >> >>        - parking to wait for  <0x8c2912a0> (a
>> >> >> java.util.concurrent.CountDownLatch$Sync)
>> >> >>        at
>> >> >>        java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
>> >> >>        at
>> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>> >> >>        at
>> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>> >> >>        at
>> >> >>        java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>> >> >>        at
>> >> >>        java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
>> >> >>        at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)
>> >> >>        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>> >> >>        at org.hsqldb.Session.executeCompiledBatchStatement(Unknown
>> >> >>        Source)
>> >> >>        at org.hsqldb.Session.execute(Unknown Source)
>> >> >>        - locked <0x54692580> (a org.hsqldb.Session)
>> >> >>        at org.hsqldb.jdbc.JDBCPreparedStatement.executeBatch(Unknown
>> >> >>        Source)
>> >> >>        - locked <0x8d3df540> (a org.hsqldb.jdbc.JDBCPreparedStatement)
>> >> >>
>> >> >> If I run multiple dumps, the read operation stays around the same
>> >> >> lines of code - that is, line changes between dumps but always stay
>> >> >> the same cyclically, as if it were in a loop - while other operations
>> >> >> are all stuck waiting for the latch.
>> >> >>
>> >> >> Has anyone experienced such a thing?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Sergio B.
>> >> >>
>> >> >> --
>> >> >> Sergio Bossa
>> >> >> http://www.linkedin.com/in/sergiob
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Better than sec? Nothing is better than sec when it comes to
>> >> >> monitoring Big Data applications. Try Boundary one-second
>> >> >> resolution app monitoring today. Free.
>> >> >> http://p.sf.net/sfu/Boundary-dev2dev
>> >> >> _______________________________________________
>> >> >> Hsqldb-user mailing list
>> >> >> [hidden email]
>> >> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Better than sec? Nothing is better than sec when it comes to
>> >> > monitoring Big Data applications. Try Boundary one-second
>> >> > resolution app monitoring today. Free.
>> >> > http://p.sf.net/sfu/Boundary-dev2dev
>> >> > _______________________________________________
>> >> > Hsqldb-user mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Better than sec? Nothing is better than sec when it comes to
>> >> monitoring Big Data applications. Try Boundary one-second
>> >> resolution app monitoring today. Free.
>> >> http://p.sf.net/sfu/Boundary-dev2dev
>> >> _______________________________________________
>> >> Hsqldb-user mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>> >
>> > ------------------------------------------------------------------------------
>> > Better than sec? Nothing is better than sec when it comes to
>> > monitoring Big Data applications. Try Boundary one-second
>> > resolution app monitoring today. Free.
>> > http://p.sf.net/sfu/Boundary-dev2dev
>> > _______________________________________________
>> > Hsqldb-user mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>>
>>
>>
>> --
>> Sergio Bossa
>> http://www.linkedin.com/in/sergiob
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Hsqldb-user mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/hsqldb-user
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Hsqldb-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/hsqldb-user



--
Sergio Bossa
http://www.linkedin.com/in/sergiob

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Hsqldb-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/hsqldb-user