You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2012/09/11 19:18:08 UTC
[jira] [Created] (DERBY-5922) BaseDataFileFactory.stop() should
provide better protection for a null storageFactory. Can cause
NullPointerException if boot fails
Kathey Marsden created DERBY-5922:
-------------------------------------
Summary: 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
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
[jira] [Assigned] (DERBY-5922) BaseDataFileFactory.stop() should
provide better protection for a null storageFactory. Can cause
NullPointerException if boot fails
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor reassigned DERBY-5922:
--------------------------------------
Assignee: Mamta A. Satoor
> 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
[jira] [Commented] (DERBY-5922) BaseDataFileFactory.stop() should
provide better protection for a null storageFactory. Can cause
NullPointerException if boot fails
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (DERBY-5922) BaseDataFileFactory.stop() should
provide better protection for a null storageFactory. Can cause
NullPointerException if boot fails
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor resolved DERBY-5922.
------------------------------------
Resolution: Cannot Reproduce
> 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