db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1338) Client tests DerbyNetNewServer and NSinSameVM fail with NoClassDefFoundError: DRDAProtocolExceptionInfo when run from classes dir
Date Mon, 19 Jun 2006 22:57:31 GMT
    [ 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.



> 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:
>  Environment: Sun JDK 1.4.2, Sun JDK 1.5
>     Reporter: Dag H. Wanvik
>     Assignee: Dag H. Wanvik
>     Priority: Minor
>      Fix For:

> 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
> *** 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:
For more information on JIRA, see:

View raw message