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
