Provide info on currently running jobs

[atomashpolskiy]

I can see two ways of accomplishing this:

1. Register start/end of job execution in RunnableJob.run() method and provide a simple API for retrieving a list of jobs, that were started but hadn't yet finished
2. Store JobFutures somewhere and provide an API for querying current (and possibly historical) data, that will be based on the list of active and completed futures

[andrus]

I like 2 as it provides both stats and job control (i.e. you can kill a job)

[atomashpolskiy]

I also like the 2nd option more, but it won't let us track periodic execution of scheduled jobs... Seems like we need a combination of both.

There also can be an (arguably rare) case when a job has been submitted for execution but not started due to shortage of thread pool workers, so it's effectively queued.
This implies that despite that bootique-job by itself skips job execution if another instance of the same job is already running, there still might be a situation when there are several "live" instances of the same job, where the first is running and all the others are queued.

[atomashpolskiy]

I should add that currently max thread pool size is unbound, so the issue with queued jobs will not happen unless we introduce an option to restrict pool capacity or a custom executor is provided by the user.

[andrus]

• JobFutures seem to be accumulating inside DefaultScheduler and are never cleaned up. Looks like a memory leak.
• In my comment on Jan 10, I overlooked the fact that we have a nice metrics framework. So # 1 solution - just sending events when something happens, and let metrics subsystem handle it - may actually be a better one. This will address the issue above too. This will require splitting bootique-job into bootique-job and bootique-job-instrumented (kind of like we do with Jetty).

[atomashpolskiy]

JobFutures seem to be accumulating inside DefaultScheduler and are never cleaned up. Looks like a memory leak.

There's a cleaner thread in the bottom of DefaultScheduler file

In my comment on Jan 10, I overlooked the fact that we have a nice metrics framework. So # 1 solution - just sending events when something happens, and let metrics subsystem handle it - may actually be a better one. This will address the issue above too. This will require splitting bootique-job into bootique-job and bootique-job-instrumented (kind of like we do with Jetty).

Let's discuss

[atomashpolskiy]

note for myself:

1. Introduce contributed listeners, that will receive "job lifecycle events". Execution params can be moved to listener method params and isRunning indicator can be removed.
2. Think about using metrics to track job execution stats (number of jobs executed, running times, and such)