db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4304) Network Server shutdown should handle exceptions and finish the server shutdown completely
Date Tue, 28 Jul 2009 01:12:14 GMT

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

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

Committed patch DERBY4304_fixNPE_patch2_diff.txt with following comments (revision 798347)

DERBY-4304

During one of the server shutdown steps, DERBY-4306 was throwing a npe(we have fixed DERBY-4306
now) and the shutdown exception handling code was calling following method on that npe 
          consolePropertyMessage("DRDA_UnexpectedException.S", exception.getMessage()); 
          consoleExceptionPrintTrace(exception); 
but the call exception.getMessage() on npe was returning null and consolePropertyMessage is
not written to handle null 2nd param for this call of consolePropertyMessage. But the work
done by this particular type of consolePropertyMessage method is also done by the next call
in the shutdown exception handling which is consoleExceptionPrintTrace. Because of this, I
have replaced the consolePropertyMessage("DRDA_UnexpectedException.S", exception.getMessage());
call with consolePropertyMessage("DRDA_UnexpectedException.S", true); This change makes sure
we do not run into npe when exception.getMessage() is null. I am not sure if we should enter
a new jira entry to make consolePropertyMessage("DRDA_UnexpectedException.S", exception.getMessage());
handle a null 2nd param. 

junit tests with this change ran into intermittent upgrade test failures. 

One last step remaining is may be write a new method which is a subset of consolePropertyMessage
because consolePropertyMessage handles the exception printing and then goes ahead and throws
the exception again. For our purposes in this jira entry, we do not want the exception to
be thrown back. instead, we want to move on to the next step in server shutdown. 

> Network Server shutdown should handle exceptions and finish the server shutdown completely
> ------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4304
>                 URL: https://issues.apache.org/jira/browse/DERBY-4304
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server
>    Affects Versions: 10.6.0.0
>            Reporter: Mamta A. Satoor
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY4304_fixNPE_patch2_diff.txt, DERBY4304_handleExceptions_patch1_diff.txt
>
>
> While working on DERBY-4053, found that an exception from Connection.close was not handled
properly by the server shutdown code which caused a new instance server startup to hang. Resolved
the problem with Connection close but in general, we should
> 1) Make sure an exception during shutdown processing does not prevent the remaining shutdown
tasks, like closing the server socket from occurring. 
> 2) Make sure any exceptions that occur in shutdown processing are reported to the console.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message