Hi guys, I'm a bit concerned of this PR https://github.com/apache/beam/pull/4637
I understand the intent but I'd like to share how I see it and why it is an issue for me: 1. you can't help if the JVM crash in any case. Tomcat had a try to preallocate some memory for instance to free it in case of OOME and try to recover but it never prooved useful and got dropped recently. This is a good example you can't do anything if there is a cataclism and therefore any framework or lib will not be blamed for it 2. if you expose an API, its behavior must be well defined. In the case of a portable library like Beam it is even more important otherwise it leads users to not use the API or the projet :(. These two points lead to say that if the JVM crashes it is ok to not call teardown and it is even implicit in any programming environment so no need to mention it. However that a runner doesn't call teardown is a bug and not a feature or something intended because it can have a huge impact on the user flow. The user workarounds are to use custom threads with timeouts to execute the actions or things like that, all bad solutions to replace a buggy API, if you remove the contract guarantee. To make it obvious: substring(from, to): will substring the current string between from and to...or not. Would you use the function? What I ask is to add in the javadoc that the contract enforces the runner to call that. Which means the core doesn't guarantee it but imposes the runner to do so. This way the not portable behavior is where it belongs to, in the vendor specific code. It leads to a reliable API for the end user and let runners document they don't respect - yet - the API when relevant. wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
