JRuby application servers that can do hot redeploys will shut down the old JRuby runtime without exiting the process. In the consumer processor, analytics-ruby creates a thread that won't shut down until the process dies. This thread will cause a stopped JRuby runtime to sit around in memory much longer than necessary (they appear to be weakrefs and as such, should eventually be GC'd).
The simple fix is to flag the thread in an at_exit handler. I did this for another project:
https://github.com/wr0ngway/lumber/blob/a35520abace41a87b455b15398be630e7ef5b2da/lib/lumber/level_util.rb#L83
The additional trick here will be to stop the consumer queue from blocking.
JRuby application servers that can do hot redeploys will shut down the old JRuby runtime without exiting the process. In the consumer processor, analytics-ruby creates a thread that won't shut down until the process dies. This thread will cause a stopped JRuby runtime to sit around in memory much longer than necessary (they appear to be weakrefs and as such, should eventually be GC'd).
The simple fix is to flag the thread in an at_exit handler. I did this for another project:
https://github.com/wr0ngway/lumber/blob/a35520abace41a87b455b15398be630e7ef5b2da/lib/lumber/level_util.rb#L83
The additional trick here will be to stop the consumer queue from blocking.