Hello,

This topic is essentially an extension to Issue #96 which led to PR #97 and the introduction of activity monitoring in the JKG.

I've implemented a solution within the JKG which introduces another internal service (idle_culler) to periodically check the current set of registered kernels to see if they've been idle for too long, at which time they are culled (deleted). The culling behavior leverages the activity monitoring and defines an idle kernel as the time since the most recent message to the client (last_message_to_client) or kernel (last_message_to_kernel). It could easily be extended to incorporate any of the other activity metrics as well. As @rwhorman mentioned in #96, the typical period of a given JKG would be on the order of 12-24 hours (again, thinking spark jobs and resource consumption). Two options have been introduced:

• KernelGatewayApp.cull_idle_kernel_period indicating the allowed idle time in seconds. Default = 0, i.e., off.
• KernelGatewayApp.cull_idle_kernel_interval indicating the frequency (seconds) at which to check for idle kernels. Default = 300.

I'd probably add units to the name and use minutes for the period, seconds for the interval.

Since I'm new to python (and open source), I wanted to run my general approach past others initially. I chose to use a separate module (services/idle_culler), but this could easily be incorporated in the activity module. The primary piece added is an IOLoop instance used to perform the periodic checks. I also added code to capture the time the kernel was culled and its idle duration at the time of its culling. The idea being that we could expose a GET request (/_api/activity/culled or /_api/culled/) to gather this information if that's desired.

I have yet to finish the handler plumbing, nor have I added any specific code to test this. Kinda wanted to make sure I'm barking up the right tree.

Does this sound like something that would be useful to include in the kernel gateway? I'd be happy to submit a PR so you can take a closer look.

Regards,
Kevin.