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

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


so, if nothing else is done I think it would be worthwhile to always log why we 
are booting a db as readonly, especially if it is not the standard place where 
we expect in getting the db lock.  It would be nicer if this was just part of 
the boot message rather than an additional message but not sure that fits in 
the code flow.

I would be concerned about the last part suggested where we just ignore the 
flush error.

It would be good to know if the problems with this wierd installation are also 
problems with the expected read only medium.  To me the following are bugs:
o any attempt to add a writable page to the cache for a non-temp table should 
just get an early
    error, rather than fail later at flush.
o any writable log action to a readonly db would be nice to get a reasonable 
error, rather npe.
   this just makes support easier.

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

Reply via email to