[
https://issues.apache.org/jira/browse/DERBY-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677439#action_12677439
]
Kathey Marsden commented on DERBY-4072:
---------------------------------------
So the exception we are not reporting is:
java.io.FileNotFoundException: /home/kmarsden/repro/10602/wombat/log/log28.dat
(Permission denied)
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:218)
at
org.apache.derby.impl.io.DirRandomAccessFile.<init>(DirRandomAccessFile.java:57)
at
org.apache.derby.impl.io.DirFile4.getRandomAccessFile(DirFile4.java:250)
at
org.apache.derby.impl.store.raw.log.LogToFile.run(LogToFile.java:5689)
at
java.security.AccessController.doPrivileged(AccessController.java:251)
at
org.apache.derby.impl.store.raw.log.LogToFile.privRandomAccessFile(LogToFile.java:5579)
at
org.apache.derby.impl.store.raw.log.LogToFile.checkJvmSyncError(LogToFile.java:5522)
at
org.apache.derby.impl.store.raw.log.LogToFile.openLogFileInWriteMode(LogToFile.java:5471)
at
org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:1074)
at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:339)
at
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019)
at
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
at
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
at
org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
at
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019)
at
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
at
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
at
org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:780)
at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:196)
at
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019)
at
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1856)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1722)
at
org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021)
at
org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
at
org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2581)
at
org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:374)
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)
at
ConnectAndShutdown.main(ConnectAndShutdown.java:9)java.io.FileNotFoundException:
and the correspoinding code in LogToFile is ~1067
if (!ReadOnlyDB)
{
// if datafactory doesn't think
it is readonly, we can
// do some futher test of our
own
try
{
if(isWriteSynced)
theLog =
openLogFileInWriteMode(logFile);
else
theLog =
privRandomAccessFile(logFile, "rw");
}
catch (IOException ioe)
{
theLog = null;
}
if (theLog == null || !privCanWrite(logFile))
{
if (theLog != null)
theLog.close();
theLog = null;
ReadOnlyDB = true;
}
}
We catch the exception and silently change the database to ReadOnly.
Later ~~`1172 we fail to initialize logOut because theLog is null
if (theLog != null)
logOut = new LogAccessFile(this,
theLog, logBufferSize);
There is another area of similar code ~986
finally during flush logOut is null so we get the NPE.
I was thinking we should
1) Log the IOExceptions.
2) Log whenever we change a database to ReadOnly.
3) In flush() if the database is ReadOnly print a warning to the log that we
cannot flush the log to a ReadOnlyDB and return.
but I don't know if this is overly verbose. Are there normal instances of the
IOException we might want to silently ignore?
> 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.
