Log in

No account? Create an account

December 28th, 2018

fedora 蓝色小药丸

Shutdown application context

Recent technical issue at work involves how a sprint-boot application shutdown itself. There are several types of applications we have over here, some are simply spring-boot web applications or scheduled applications, which should never shutdown. Some are SQS listeners that also do not shutdown. On the other hand, there are batch type of applications that should shutdown gracefully. And such batch type might be SQS listeners too. So someone built a SQS handler that can shutdown when after a given time there is no message, and another guy built an override handler that also shutdown when a message matches some criteria (it does not matter if message is handled, it seems nobody cares as the message will be retried in the next scheduled batch). And some batch simply shutdown after it is done. The technical issue was that, they refuse to shutdown. It turns out such application has defined DataSource bean using the commons-dbcp2 module. In there there is a thread pool that has to be destroyed by calling BasicDataSource.close(), which is automatically done by spring-boot if everything is configured as intended. But in one case, the DataSource is not defined as a bean, so its "close()" method is not called. The IDE was able to catch some errors but the stack trace was wrong — did not show the problematic DataSource but point to a different one. In another case, DataSource has JMX warnings after application shutdown, so instead of disabling JMX, developer added (destroyMethod="") to the bean annotation, which means the "close()" method is ignored by spring-boot. Finally, some application does not close its application context. It is fine to ignore the "close()" in most cases, as most applications are supposed to run forever. And if the context is closed for a web application, such application will shutdown immediately after startup. Having subtle difference in an often boilerplate "Main" class is not a good practice when there are so many modules to maintain.. and it caused problem. If developer has to call System.exit(0) that is a bad smell.

Read more...Collapse )