db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Huwig (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2835) Getting SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE
Date Sat, 16 Jun 2007 15:12:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505475

Kurt Huwig commented on DERBY-2835:

The c500.dat file containing the table is 4304732160 bytes long (4.009 GiB) and contains between
3,0 and 3,5 mio. entries

> ------------------------------------------------------------
>                 Key: DERBY-2835
>                 URL: https://issues.apache.org/jira/browse/DERBY-2835
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Sun JDK 1.5
>            Reporter: Kurt Huwig
> I get messages like this about once a week:
> WARNING: While deleting a row from a table the index row for base table row (50813,81)
was not found in index with conglomerate id 1.297.  This problem has automatically been corrected
as part of the delete operation.
> I do not have a reproducing example besides the productive server, so here some hints
what it is doing and what happened the last few days:
> The table in question is a log file which gets a lot of updates and once it reaches a
certain limit, the oldest records will be deleted once per day.
> The database is embedded and accessed both embedded and via one network client on another
machine. Nearly all read/write requests come from the network client.
> The table's size is about 3,8 GB and contains a lot of entries (cannot check right now).
> The JVM is sometimes stopped via "killall java".
> Both machines are Linux-SMP.
> Both machines use HA-JDBC to access the database.
> Both machines have 1,5GB of memory.
> The JVM is started with -Xmx768M -Xms768M -Xss128k
> The application uses no transactions on this table.
> The network client used 4000+ simultaneous connections, sometimes reaching the ulimit
of the machine. The number of connections has been reduced to 1/10 and the ulimit has been
increased a few days ago. Still there are records in the database from this time.
> The network connection sometimes broke down as described in DERBY-2747.
> The network client gets "lock timeouts" several times a day, due to long running requests.
> The network client had a OutOfMemoryException regarding the Heap some days ago.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message