db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1465) NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start
Date Mon, 15 Dec 2008 18:45:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Myrna van Lunteren updated DERBY-1465:

    Attachment: DERBY-1465.diff6

Attaching a next iteration - DERBY-1465.diff6

Dan's comment cited by Knut Anders:
"There is a chance the server can fail to start but the start method will not throw any exceptions,
because the waiter is notified before 'runtimeException' is set, thus the waiter may see runtimeException
as null and not throw an exception"
was actually addressed by patch 4.
(patch 5 corrected the fact that the runtimeException never got set to null, so you'd get
that message all the time).

Patch 6 I think addresses the second logic issue spotted by Knut Anders:
"since blockingStart() calls startNetworkServer() before the try/finally block, it's possible
that an exception is thrown without completedBoot being set to true, which will leave the
main thread waiting forever"
This is addressed by (simply) setting completedBoot to true when an error is encountered.

I ran NSinSameTest withouth problems 50 times (this at one time would reproduce the hang occassionally).
I ran suitesall 4 times on 2 different windows machines, and derbyall once, and I hit the
following known problems:
- DERBY-654; derbyall: unit/T_RawStoreFactory.unit
< -- Unit Test T_RawStoreFactory finished
 2 add
 > There should be 0 observers, but we still have 1 observers.
> Shutting down due to unit test failure.
   (maybe this is a j9 technology issue rather than j2me).
- DERBY-3915: 
1) testReplication_Local_3_p3_StateNegativeTests
junit.framework.AssertionFailedError: Expected SQLState'08004', but got connection!
-  DERBY-3689:
1) testAttributeAccumulatedConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)
java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: 
- DERBY-3757:
1) testStressMulti(org.apache.derbyTesting.functionTests.tests.multi.StressMultiTest)junit.framework.AssertionFailedError:

Caused by: 
java.sql.SQLException: Java exception: 'ASSERT FAILED transaction table has null entry: 

In addition, I got: 
1) ttestSetPortPriority(org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest)
junit.framework.AssertionFailedError: failed to start server with port 1529
	at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.checkWhetherNeedToShutdown(ServerPropertiesTest.java:378)
I think this is probably the same as DERBY-3873, or DERBY-2779, but because we now throw the
Exception when the server doesn't start, we see the problem earlier. Which is exactly what
this fix is intended to do.

So I think this is ok now.

Ready for review.

> NetworkServerControl.start() should throw an exception and not just  print  exceptions
 if the server fails to start
> --------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1465
>                 URL: https://issues.apache.org/jira/browse/DERBY-1465
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions:
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: DERBY-1465.diff3, DERBY-1465.diff4, DERBY-1465.diff5, DERBY-1465.diff6,
DERBY-1465_diff.txt, DERBY-1465_diff.txt, DERBY-1465_stat.txt, DERBY-1465_stat.txt, releaseNote.html,
releaseNote.html, releaseNote.html
> NetworkServerControl.start()  will not throw an exception  if another server is already
running on the same port.    I am not sure but think perhaps this was changed at  one point
to accomodate the derby.drda.startNetworkServer property  so that the embedded server could
continue to boot even if the network server failed to start, but  I think this is wrong for
normal usage.
> http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html

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

View raw message