db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Date Mon, 18 Jun 2007 19:05:29 GMT

     [ 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

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).

> ------------------------------------------------------------
>                 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