Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <601316754.1235760072766.JavaMail.jira@brutus>
Date: Fri, 27 Feb 2009 10:41:12 -0800 (PST)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4072) shutdown with incorrect permission on
 log files shows java.lang.NullPointerException  at
 org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3964).
  Should give bettter message.
In-Reply-To: <418354252.1235602381910.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4072:
----------------------------------


I am not sure best way to do the following, but thought I would at least first comment on what the goal should be.  The whole "readonly" code I think is weak.  It was mostly put in to allow a derby db to be put on and run directly from something like a cd, and to be zero-admin, ie. not force people to somehow createdb a readonly db.  We expect to determine a readonly db when we get the lock on the database lock file which requires writing to the file.  it never really was 
designed for these "half-readonly" cases.

The problem as this case shows is that catching exceptions and interpreting them may lead to the wrong conclusions.  

So for instance I would say that we should not boot if we think the db is readonly but we find work to do during restart recovery.  This is effectively what the code does but delays the error to sometime in the future and a NPE.  The possible problems with allowing boot to continue are:
o if redo recovery has anything to do then it will fill up the cache with dirty pages, and on shutdown
   or earlier we may try to write those pages out and if the db is read only get errors.
o if redo recovery has anything to abort then it will have to write extra stuff to the log file and if 
   existing log file is not writable or new logfiles are not writeable then we may get wierd errors
   during boot.
Both the above may be existing problems in the code with a readonly cd version, I don't know.
I think in both these cases we should fail the boot and make sure somehow errors get printed saying exactly why we thought the db was readonly and that recovery code not run as it found
necessary writable work to do.

Unfortunately I think we still want to support finding some log files in a readonly db as a very normal situation would be for a customer to load up a db, then do a clean shutdown and then copy the full db to the cd.  This will still leave some log files, but no work to do.


> shutdown with incorrect permission on log files shows java.lang.NullPointerException  at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3964).  Should give bettter message.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4072
>                 URL: https://issues.apache.org/jira/browse/DERBY-4072
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: ConnectAndShutdown.java, InsertALot.java, MakeDB.java
>
>
> I recently saw  case where a user was seeing the following error in the derby.log when trying to shutdown their database.
> New exception raised during cleanup null
> java.lang.NullPointerException
>         at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3964)
>         at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:1781)
>         at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.flush(BaseDataFileFa
>         at org.apache.derby.impl.store.raw.data.CachedPage.writePage(CachedPage.java:761
>         at org.apache.derby.impl.store.raw.data.CachedPage.clean(CachedPage.java:610)
>         at org.apache.derby.impl.services.cache.ConcurrentCache.cleanAndUnkeepEntry(Conc
>         at org.apache.derby.impl.services.cache.ConcurrentCache.cleanCache(ConcurrentCac
>         at org.apache.derby.impl.services.cache.ConcurrentCache.cleanAll(ConcurrentCache
>         at org.apache.derby.impl.services.cache.ConcurrentCache.shutdown(ConcurrentCache
>         at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFac
>         at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:405)
>         at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:34
>         at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:
>         at org.apache.derby.impl.db.DatabaseContextImpl.cleanupOnError(DatabaseContextIm
>         at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(ContextM
>         at org.apache.derby.impl.jdbc.TransactionResourceImpl.cleanupOnError(Transaction
>         at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:584)
>         at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)
>         at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:238)
>         at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
>         at java.sql.DriverManager.getConnection(DriverManager.java:316)
>         at java.sql.DriverManager.getConnection(DriverManager.java:273)
> It ended up that some of the log files did not have proper write permissions because some operation on the database had been performed by root.   They had subsequently deleted their db.lck file so the database did not boot READ ONLY as it would if the root owned db.lck file still existed and the symptom was that they got this error on shutdown.
> Clearly this was user error, but it would have been good if we gave a better error message.  To reproduce on Linux:
> As a user with umask 0022, run the program 
> java MakeDB
> this will make the databases wombat and create a table.
> su root
> with umask 0022, run the program to insert data and remove the db.lck file:
> java InsertALot
> rm wombat/db.lck
> go back to the original user
> run the program:
> java ConnectAndShutdown
> The application gets the normal shutdown exception but if you look in derby.log you will see the exception.
> java.lang.NullPointerException
>         at org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3964)
>         ...
> I will attach the files.

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