[ http://issues.apache.org/jira/browse/DERBY-1338?page=comments#action_12416817 ]
Dag H. Wanvik commented on DERBY-1338: -------------------------------------- From: Bryan Pendleton, Date: Tue, 23 May 2006 16:17:59 -0700 > The shutdown of the server *has* interrupted the thread, in > NetworkServerStarter#blockingStart. So, is this the reason we get this > exception? This is *very* interesting -- thank you for doing this great research! This sort of thing is exactly why I've been so scared to add more calls to interrupt() as part of DERBY-1219 and DERBY-1326 -- interrupt() is a very scary call to make. The good news is that this does mean that this is purely a shutdown problem, as the only place that we interrupt the DRDAConnThread instances right now is at the very end of the blockingStart() method. But it certainly means we'll have to be even more careful about whatever fix we eventually make for DERBY-1326, as we definitely don't want to casually add any more interrupt() calls, given the possibility of horrible side effects like this. > As I mentioned before, we can make sure the classes in question > (DRDAProtocolExceptionInfo and DRDAProtocolException) are already > loaded (by creating a dummy object) before the thread is interrupted, > thus sidestepping the issue. Alternatively, we could remove the interrupt() call in Network Server shutdown. Since we are shutting down the server anyway, I don't know how crucial it is to clean up those background threads. We have called close() on them already, so if they try to run again, they will quickly detect that they have been closed and exit themselves. And, so long as they have been marked as "daemon" threads, their mere presence won't prevent the server from shutting down. But I'm also fine with pre-loading the classes if that seems to help. These sorts of startup/shutdown bugs always seem very hard to me: trying to shut down a complex piece of server software while all sorts of complicated processing may be still underway has always been a dicey business. thanks, bryan > Client tests DerbyNetNewServer and NSinSameVM fail with NoClassDefFoundError: > DRDAProtocolExceptionInfo when run from classes dir > --------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1338 > URL: http://issues.apache.org/jira/browse/DERBY-1338 > Project: Derby > Type: Bug > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: Sun JDK 1.4.2, Sun JDK 1.5 > Reporter: Dag H. Wanvik > Assignee: Dag H. Wanvik > Priority: Minor > Fix For: 10.2.0.0 > > When run from Sun JDK 1.4.2 and Sun JDK 1.5, these two tests fail when run > from the > classes directory. They work, though, when run from jars. > Running NSinSameVM in my sandbox: > bash-3.00$ java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest > derbynet/NSinSameJVM.java > *** Start: NSinSameJVM jdk1.4.2_05 DerbyNetClient 2006-05-22 14:49:05 *** > Initialize for framework: DerbyNetClient > startServer = false. Bypass server startup > 6 add > > java.lang.NoClassDefFoundError: > > org/apache/derby/impl/drda/DRDAProtocolExceptionInfo > Test Failed. > *** End: NSinSameJVM jdk1.4.2_05 DerbyNetClient 2006-05-22 14:49:27 *** > I get similar behavior for DerbyNetNewServer. I ran this on a Solaris > 10/i86x box. Davis has seen it too, see > initial discusson on this thread: > http://www.nabble.com/forum/ViewPost.jtp?post=4477600&framed=y -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
