+972 52-548-6969
The “features” that no one talks about makes all the difference
You might have noticed that I am talking a lot about support and operations recently. This is because we have been doing a lot of work around that area. Making sure that RavenDB is even more forthcoming and open about what is going on.
This week it has been about making sure that the shutdown phase of RavenDB is as transparent as it could be. Debugging those sort of issues is a PITA, because you very rarely really stop to consider them. But we got some feedback from customers about a common set of issues there.
Under some circumstances, shutting down RavenDB might take a while. We identified several things that can cause this, mostly indexing in progress.
The first thing we did is change the way we are doing indexing to allow aborting them during shutdown, but there are still a set of operations that might take a while that we have to complete even in shutdown scenario.
For example, we might be just in the middle of flushing to disk, and we really want that to complete successfully (otherwise we would need to run an expensive check on startup).
Therefor, we added this:
You’ll still have to wait, sure. But now if you watch the logs you can see why, and have some understanding about how long this is going to take.
Comments
You mean like the same expensive check at startup when the process crashes or got killed?
Yves, I am not following.
Well, you've shown us the graceful shutdown process. What happens - when the process dies (for whatever reason) - to those things you "really" want to complete successfully? I assume you recover from such things upon restart by checking integrity, no? Granted, it's a bit off topic.
Yves, Oh, sure, we had that for a long while.
I guess my question - albeit a rhetoric one - was, beyond the fact you're being proactive in communicating why shut down is taking so long, the check happens at start-up, regardless (although I assume it to be fairly cheap if all is well) of a successful or faulty shutdown.
Yves, It is cheap to tell if we had a good shutdown, expensive if we had a bad one.
Paying attention to operations and support requirements is the software equivalent of the old saying that amateurs study tactics and professionals study logistics.
what's the reason for localReason variable?
Karep, The value of the original string might change during this method.
Comment preview