[
https://issues.apache.org/jira/browse/DERBY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2835:
----------------------------------
I assume you the data in the database can't be made public, but the more info
you can post the better we can understand
the issue.
Can you post the ddl of the table, along with any of it's indexes. Are there
any triggers on this table? How many processors?
By no transactions, I assume that means autocommit on. Do you monitor
derby.log, if you don't already you should set
the system to save this log file permanently: derby.log.append
http://db.apache.org/derby/docs/10.2/tuning/rtunproper13217.html
Do you set any specific properties for this database. For instance do you set
derby.system.durability?
Is there any way for both machines to access the same filesystem (ie. some sort
of share file system)? Is there any way that
you might be access the same database from 2 different classloaders in the same
jvm (ie. DERBY-700).
> 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.
