[ 
https://issues.apache.org/jira/browse/DERBY-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469060#comment-13469060
 ] 

Mamta A. Satoor commented on DERBY-5916:
----------------------------------------

It definitely is a good idea to check if storageFactory is null before calling 
shutdown on it in BaseDataFileFactory.stop(). But I believe we may have gotten 
NPE somewhere else, especially if we are talking about Derby 10.6 or prior.

I spent some more time looking at the code in trunk and right before the 
following check in BaseDataFileFactory.stop()
        if (isReadOnly()) // do enough to close all files, then return 
        {
            storageFactory.shutdown();
            return;
        }
there is following code
                removeTempDirectory();
The call to removeTempDirectory() leads to 
    public final Object run() throws IOException, StandardException
    {
        switch( actionCode)
        {
        .....;
            
        case REMOVE_TEMP_DIRECTORY_ACTION:
            StorageFile tempDir = storageFactory.getTempDir();
            if( tempDir != null)
                tempDir.deleteAll();
            return null;
If storageFactory was null, we would have gotten NPE here before we even reach 
the code where we call storageFactory.stop() in BaseDataFileFactory.stop()

I will be interested in knowing what version of Derby was being used by the 
user of this jira. If my theory is correct, then may be they were using 10.6 or 
earlier release. In 10.6 and prior codelines, we have following piece of code 
in BaseDataFileFactory.stop() towards the beginning of the method
                long shutdownTime = System.currentTimeMillis();
                boolean logBootTrace = 
PropertyUtil.getSystemBoolean(Property.LOG_BOOT_TRACE);
                istream.println(LINE);
                logMsg("\n" + new Date() +
Note, that we call istream.println(LINE) without checking if istream is null. 
This was fixed by Knut as part of DERBY-4873 but that fix went into 10.7. The 
fix was to use the helper method logMsg() which looks for istream being null 
and initializing it properly in case it is found null. I think it will be good 
idea to backport this change from DERBY-4873 to 10.6 and earlier releases.
                
> java.lang.NullPointerException 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop() connecting to 
> network server
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5916
>                 URL: https://issues.apache.org/jira/browse/DERBY-5916
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>              Labels: derby_triage10_10
>         Attachments: DERBY5916_patch1_diff.txt
>
>
>  I got a report of the exception below trying to connect to  database with 
> absolute path and network server and the database name attribute.  I haven't 
> gotten  information  on the derby version or  platform, Below is the url I 
> received with some characters replaced.
> ij> connect 
> 'jdbc:derby://localhost:1527/;databaseName=/home/uxxxx/Installs/hxxx_ext/mxxxxxxxx_db;create=true'
>  ;
>  java.lang.NullPointerException
>         at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(Unknown Source)
>         at org.apache.derby.impl.services.monitor.TopService.stop(Unknown 
> Source)
>         at org.apache.derby.impl.services.monitor.TopService.shutdown(Unknown 
> Source)
>         at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
>         at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown
>  Source)
>         at 
> org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown
>  Source)
>         at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown
>  Source)
>         at 
> org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown 
> Source)
>         at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown 
> Source)
>         at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
>         at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown 
> Source)
>         at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
>         at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
>         at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source)
>         at 
> org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown 
> Source)
>         at 
> org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown 
> Source)
>         at 
> org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown 
> Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> Cleanup action completed
> 2012-08-31 22:41:09.216 GMT Thread[DRDAConnThread_10,5,main] (DATABASE = ), 
> (DRDAID = {1}), Java exception: ': java.lang.NullPointerException'.
> I wanted to go ahead and file it even without much information as I noticed 
> there was a similar issue reported on the list but never filed:
> http://old.nabble.com/Random-DRDA-Error-on-IBM-J9-JVM-td33532717.html#a33532717

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to