[DISCUSS] Refactor job scheduler

[Erik Wramner <er...@wramner.name>]

I'm considering implementing a JDBC job scheduler store. The current 
state of affairs where there is only a memory and KahaDB job scheduler 
store means that it is impossible to use JDBC as a highly available 
backend with scheduled messages, including messages scheduled by the 
redelivery plugin. However, in my view the job scheduler store interface 
is deeply flawed.

The problem is that the store does nothing. It can get or set a 
directory (useless with JDBC), it can return the number of jobs 
scheduled (OK) and it can return or remove job schedulers. The job 
schedulers do all the heavy lifting.

This works, but it means that every time a new persistence mechanism is 
added we must implement the scheduler again. I really don't want to 
implement a job scheduler just to save jobs to a database instead of to 
the file system (with KahaDB). I think it would be much better if we 
could refactor the JobSchedulerStore interface to provide the 
persistence operations that are used by the two existing schedulers. 
That way it would be much easier to write a JDBC scheduler store and a 
LevelDB scheduler store and a new-exciting-storage-not-yet-available 
scheduler store without reinventing the wheel (the basic scheduling) 
every time.

What do you think?

-Erik

Re: [DISCUSS] Refactor job scheduler

[Gary Tully <ga...@gmail.com>]

that makes good sense. There is an open issue on this -
https://issues.apache.org/jira/browse/AMQ-5238

On Sat, 26 Sep 2015 at 13:30 Erik Wramner <er...@wramner.name> wrote:

> I'm considering implementing a JDBC job scheduler store. The current
> state of affairs where there is only a memory and KahaDB job scheduler
> store means that it is impossible to use JDBC as a highly available
> backend with scheduled messages, including messages scheduled by the
> redelivery plugin. However, in my view the job scheduler store interface
> is deeply flawed.
>
> The problem is that the store does nothing. It can get or set a
> directory (useless with JDBC), it can return the number of jobs
> scheduled (OK) and it can return or remove job schedulers. The job
> schedulers do all the heavy lifting.
>
> This works, but it means that every time a new persistence mechanism is
> added we must implement the scheduler again. I really don't want to
> implement a job scheduler just to save jobs to a database instead of to
> the file system (with KahaDB). I think it would be much better if we
> could refactor the JobSchedulerStore interface to provide the
> persistence operations that are used by the two existing schedulers.
> That way it would be much easier to write a JDBC scheduler store and a
> LevelDB scheduler store and a new-exciting-storage-not-yet-available
> scheduler store without reinventing the wheel (the basic scheduling)
> every time.
>
> What do you think?
>
> -Erik
>