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 Mon, 18 Jun 2007 20:49:25 GMT

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

Kurt Huwig commented on DERBY-2835:
-----------------------------------

The filesystem is a ReiserFS and the "sync" option is not used.

The database has been rebuilt about a week ago by creating it and adding the ~3 mio entries
in this particular table.

I will check if we can activate the log. There should be enough disk space for some time.

The database is confidential and 486MB gzip compressed.

The DDL is

CREATE TABLE journal(
  ID VARCHAR(20) PRIMARY KEY default '' NOT NULL,
  IP VARCHAR(45) default '' NOT NULL,
  SENDER VARCHAR(32000) default '' NOT NULL,
  RECIPIENT VARCHAR(32000) default '' NOT NULL,
  MAILSENDER VARCHAR(32000) default '' NOT NULL,
  MAILFROM VARCHAR(32000) default '' NOT NULL,
  MAILTO VARCHAR(32000) default '' NOT NULL,
  CC VARCHAR(32000) default '' NOT NULL,
  BCC VARCHAR(32000) default '' NOT NULL,
  REPLYTO VARCHAR(32000) default '' NOT NULL,
  MAILDATE TIMESTAMP default '0001-01-01 00:00:00',
  RECEIVEDDATE TIMESTAMP default '0001-01-01 00:00:00' NOT NULL,
  SUBJECT VARCHAR(32000) default '' NOT NULL,
  TOTALLENGTH BIGINT default 0 NOT NULL,
  ATTACHMENTS VARCHAR(32000) default '' NOT NULL,
  SPAMSCORE DOUBLE NOT NULL,
  STATUS VARCHAR(11) default 'aborted' NOT NULL,
  REASON VARCHAR(32000) NOT NULL);
CREATE INDEX journal_receiveddate_desc ON journal(receiveddate DESC);

No special properties have been set besides mandatory password authentication.

The two machines do not share the filesystem.

There is an embedded Tomcat running in the same JVM, but according to the logs, the database
is not booted twice.

The only reasons for the failure I can think of were the failed network connections, the OutOfMemoryError
or the 4000+ simultaneous connections together with lock timeouts.

Ah and I am running 10.2 SVN 540841, as this fixes DERBY-2549.

> Getting SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE
> ------------------------------------------------------------
>
>                 Key: DERBY-2835
>                 URL: https://issues.apache.org/jira/browse/DERBY-2835
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.0
>         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.


Mime
View raw message