db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@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.
Date Fri, 27 Feb 2009 18:41:12 GMT

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


Mime
View raw message