Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Sat, 6 Oct 2012 18:53:03 +0000 (UTC)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <839730702.5343.1349549583425.JavaMail.jiratomcat@arcas>
In-Reply-To: <93775778.64251.1347383888154.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (DERBY-5922) BaseDataFileFactory.stop() should
 provide better protection for a null storageFactory. Can cause
 NullPointerException if boot fails
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Uable to repro this problem but changes made for DERBY-5916 should help to get more information if this happens again. Additionally, backport of DERBY-4873 (NullPointerException in testBoundaries with ibm jvm 1.6) to 10.6 and 10,5 should help too if the user is using any one of those 2 releases.
                
> BaseDataFileFactory.stop() should provide better protection for a null storageFactory. Can cause NullPointerException if boot fails
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5922
>                 URL: https://issues.apache.org/jira/browse/DERBY-5922
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Store
>    Affects Versions: 10.9.1.0
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>
> DERBY-5916 was a report of a NullPointerException in BaseDataFileFactory.stop()
> Although we don't know the root cause or have a reproduction of the problem reported in that issue. As Brian points out ..
> "It sounds like there was such a severe error trying to start up the database that
> we were trying to abort the startup and shutdown the parts that did start.
> But we were in a state where, having failed to start up, we couldn't shut down, either.
> BaseDataFileFactory.stop is very thorough with its null pointer checks, so it's not
> easy to see how that code could get a NPE.
> But I notice that line 532, the call to storageFactory.shutdown in this:
>         if (isReadOnly()) // do enough to close all files, then return
>         {
>             storageFactory.shutdown();
>             return;
>         }
> isn't protected by "if( storageFactory != null )"
> Perhaps you could reproduce this artificially by arranging by forcing
> the startup code to throw an exception at just the right point...
> "
> It would be good to fix at least the null checks. Perhaps the NullPointerException is masking the original error.

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