Stopping a java.lang.ref.Cleaner's background thread

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Stopping a java.lang.ref.Cleaner's background thread

Dávid Karnok
Hello.

Java 9 introduced the handy and official Cleaner infrastructure to replace the functionality of finally(). It allows us to create the thread it is going to use for the cleanup, which is set to daemon so that the JVM can quit. 

However, when running in an "app" container such as Tomcat, I'm not sure how to cleanup the Cleaner itself when the servlet gets unloaded. (We had similar issues with RxJava's own set of standard schedulers which made us expose the shutdown of the underlying thread pools so a servlet can stop them when it gets unloaded.)

I'm not sure what the effect of such shutdown should be beyond stopping the underlying threadpool. Calling clean() on all registered Cleanables and rejecting further register() calls? Returning all registered Cleanables?

--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Stopping a java.lang.ref.Cleaner's background thread

Roger Riggs
Hi David,

It should not be necessary to do anything to the Cleaner thread. 
The thread is set to be a daemon, so it will not inhibit a clean return from main.
Also, the Cleaner thread will stop itself when all of the cleaner functions have done their cleanup.

Regards, Roger


On 9/7/2017 4:55 AM, Dávid Karnok wrote:
Hello.

Java 9 introduced the handy and official Cleaner infrastructure to replace the functionality of finally(). It allows us to create the thread it is going to use for the cleanup, which is set to daemon so that the JVM can quit. 

However, when running in an "app" container such as Tomcat, I'm not sure how to cleanup the Cleaner itself when the servlet gets unloaded. (We had similar issues with RxJava's own set of standard schedulers which made us expose the shutdown of the underlying thread pools so a servlet can stop them when it gets unloaded.)

I'm not sure what the effect of such shutdown should be beyond stopping the underlying threadpool. Calling clean() on all registered Cleanables and rejecting further register() calls? Returning all registered Cleanables?

--
Best regards,
David Karnok


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Stopping a java.lang.ref.Cleaner's background thread

Gil Tene-2
I think David is asking about "leaking" the associated cleaner thread if it was created by a servlet (e.g. as a shared static member if the servlet׳s class or library), and the servlet gets unloaded. The key wording for the Javadoc about this is:

"...The thread runs until all registered cleaning actions have completed and the cleaner itself is reclaimed by the garbage collector."

So when the last strong reference from the servlet to the cleaner goes away (when the servlet is unloaded), the cleaner itself will be presumably be cleaned (using some other systemic cleaner), and that will stop the thread and eventually collect up.

Sent from my iPad

On Sep 7, 2017, at 6:40 AM, Roger Riggs <[hidden email]> wrote:

Hi David,

It should not be necessary to do anything to the Cleaner thread. 
The thread is set to be a daemon, so it will not inhibit a clean return from main.
Also, the Cleaner thread will stop itself when all of the cleaner functions have done their cleanup.

Regards, Roger


On 9/7/2017 4:55 AM, Dávid Karnok wrote:
Hello.

Java 9 introduced the handy and official Cleaner infrastructure to replace the functionality of finally(). It allows us to create the thread it is going to use for the cleanup, which is set to daemon so that the JVM can quit. 

However, when running in an "app" container such as Tomcat, I'm not sure how to cleanup the Cleaner itself when the servlet gets unloaded. (We had similar issues with RxJava's own set of standard schedulers which made us expose the shutdown of the underlying thread pools so a servlet can stop them when it gets unloaded.)

I'm not sure what the effect of such shutdown should be beyond stopping the underlying threadpool. Calling clean() on all registered Cleanables and rejecting further register() calls? Returning all registered Cleanables?

--
Best regards,
David Karnok


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Stopping a java.lang.ref.Cleaner's background thread

Roger Riggs
Hi Gene,

Right, I didn't think to mention the baseline of needing to completely free all objects
related to the library or subsystem.  That's a necessary step to avoid leaks in any unloading
scenerio and bottoms out in the classloaders and statics.

Thanks, Roger

On 9/7/2017 10:28 AM, Gil Tene wrote:
I think David is asking about "leaking" the associated cleaner thread if it was created by a servlet (e.g. as a shared static member if the servlet׳s class or library), and the servlet gets unloaded. The key wording for the Javadoc about this is:

"...The thread runs until all registered cleaning actions have completed and the cleaner itself is reclaimed by the garbage collector."

So when the last strong reference from the servlet to the cleaner goes away (when the servlet is unloaded), the cleaner itself will be presumably be cleaned (using some other systemic cleaner), and that will stop the thread and eventually collect up.

Sent from my iPad

On Sep 7, 2017, at 6:40 AM, Roger Riggs <[hidden email]> wrote:

Hi David,

It should not be necessary to do anything to the Cleaner thread. 
The thread is set to be a daemon, so it will not inhibit a clean return from main.
Also, the Cleaner thread will stop itself when all of the cleaner functions have done their cleanup.

Regards, Roger


On 9/7/2017 4:55 AM, Dávid Karnok wrote:
Hello.

Java 9 introduced the handy and official Cleaner infrastructure to replace the functionality of finally(). It allows us to create the thread it is going to use for the cleanup, which is set to daemon so that the JVM can quit. 

However, when running in an "app" container such as Tomcat, I'm not sure how to cleanup the Cleaner itself when the servlet gets unloaded. (We had similar issues with RxJava's own set of standard schedulers which made us expose the shutdown of the underlying thread pools so a servlet can stop them when it gets unloaded.)

I'm not sure what the effect of such shutdown should be beyond stopping the underlying threadpool. Calling clean() on all registered Cleanables and rejecting further register() calls? Returning all registered Cleanables?

--
Best regards,
David Karnok


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest