The more I look at this issue I think the problem is that the istat daemon should shutdown and not return until it has completed this
shutdown when indexRefresher.stop(); is called from the DataDictionary's stop call(). For a clean shutdown of the system the store
needs all it's clients shutdown first and then it can cleanly shutdown, and force the database files and transaction logs insuring
a clean shutdown with no recovery work necessary on the next boot.
By leaving the istat daemon running we can run into a number of errors that I don't think can be solved. We might fix a specific one shown
up by this test but the system is just not designed to handle clean shutdown while stuff is still running without first waiting for the running
stuff to stop somehow.
Kristian noted in
> I think Mike's comments/observations above agree pretty much with my thinking when writing the code. Seems there are several error-handling issues to iron out though...
>A few specific comments:
>o I decided to not make Derby wait for the background thread to finish on shutdown, as it might potentially be scanning a very large table.
>o Logging is rather verbose now during testing, but I agree it should be less verbose (or maybe turned off completely) when released.
>o I'm logging a lot of exceptions to aid testing/debugging. These should also go away, or be enabled by a property if the user wishes to do so.
I now think that it was wrong to not wait for the background thread. This would match the behavior of the rawStoreDaemon thread which is "owned"
by the raw store module - the module stops the daemon and the daemon waits around for work to stop/complete before returning from the stop, and
then the raw store continues with it's data and transaction file cleanup prior to stopping. I agree it would be a nice optimization to somehow stop the background thread in
the middle of a big scan, and it seems like with the better interrupt support this should be much easier than was the case before 10.8. I would like
some feedback before proceding from those more knowledgeable about the istat work.
I do think that the work rick did for
DERBY-5037 is still valuable as it will handle much better the non-clean shutdowns that Derby can experience. ButFor
a non-clean shutdown we might have to just live with a file left open until the thread or jvm exits. But for a requested orderly shutdown of the system I
think we should go with the top down shutdown supported by the architecture rather than try to fix errors encountered when top level modules are still
running while lower level modules are trying to shut down.