Is your feature request related to a problem? Please describe.
I have the following usecase: a cluster setup with two nodes. I'd like to run periodic jobs. The jobs read data from a database, process it, then write data back to the database. To improve performance, I want to keep a cache of intermediate data between job runs. The amount of intermediate data is relatively large, so persisting it to the database between job runs would not make much sense (then I could just not use a cache after all). So want to keep this cached data in-memory.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]*
AFAICT, in a quartz cluster setup, a job runs semi-randomly on one of the nodes and I have no guarantee that a periodically triggered job always runs on the same node. That's why I cannot use in-memory caching between runs as I'd like.
Describe the solution you'd like
Ideally, I'd like to be able to specify that a job should be "pinned" to a node: at the first job-run, a node is chosen randomly. But from then on out, consecutive runs of that job always will be executed on the same node as the first run. Only in case of a failure of the node, the job should be switched to the other node.
If that's not possible, I'd also settle for a different approach, where I have to specify the node a job should run on manually.
In general, I'd like to have more control over which node runs a job.
Describe alternatives you've considered
I've thought about using an additional local scheduler that is configured to run the job and use that only on one of the nodes. The problem is that this requires manual intervention in case of a node failure to get the jobs running again.
I've also thought about a combination of local and distributed/clustered scheduler instances: a distributed job first picks the "correct" node to run on, then triggers a local job on that node that does the actual work. Problem here is - again - that there is no way to tell quartz to run the local job on a specific node. Variation of that idea: running the distributed job in a high frequency and hope that it gets executed on the correct node, which I'd detect and if so, trigger the local job. Seems less that ideal though...
I might have overlooked something crucial in the docs or misunderstood things... if so, please tell me! :)
Is your feature request related to a problem? Please describe.
I have the following usecase: a cluster setup with two nodes. I'd like to run periodic jobs. The jobs read data from a database, process it, then write data back to the database. To improve performance, I want to keep a cache of intermediate data between job runs. The amount of intermediate data is relatively large, so persisting it to the database between job runs would not make much sense (then I could just not use a cache after all). So want to keep this cached data in-memory.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]*
AFAICT, in a quartz cluster setup, a job runs semi-randomly on one of the nodes and I have no guarantee that a periodically triggered job always runs on the same node. That's why I cannot use in-memory caching between runs as I'd like.
Describe the solution you'd like
Ideally, I'd like to be able to specify that a job should be "pinned" to a node: at the first job-run, a node is chosen randomly. But from then on out, consecutive runs of that job always will be executed on the same node as the first run. Only in case of a failure of the node, the job should be switched to the other node.
If that's not possible, I'd also settle for a different approach, where I have to specify the node a job should run on manually.
In general, I'd like to have more control over which node runs a job.
Describe alternatives you've considered
I've thought about using an additional local scheduler that is configured to run the job and use that only on one of the nodes. The problem is that this requires manual intervention in case of a node failure to get the jobs running again.
I've also thought about a combination of local and distributed/clustered scheduler instances: a distributed job first picks the "correct" node to run on, then triggers a local job on that node that does the actual work. Problem here is - again - that there is no way to tell quartz to run the local job on a specific node. Variation of that idea: running the distributed job in a high frequency and hope that it gets executed on the correct node, which I'd detect and if so, trigger the local job. Seems less that ideal though...
I might have overlooked something crucial in the docs or misunderstood things... if so, please tell me! :)