You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/11/29 05:45:24 UTC
Quartz spike
Gang,
I have now spent too many weekends on the Scheduler library.
a. What we have doesn't work as expected.
b. I have not been able to fix it.
c. I have tried to use Quartz by re-implementing a JobStore, backed by
our persistence. It is highly complicated. Quartz have not managed to
separate the concerns well enough, and too much JDBC assumptions are in
place. I give up on this. I can push my local branch on what I have done,
if someone is interested in picking this up and run with it.
d. Other hacks are possible, but simply feels utterly wrong. Having a RAM
based JobStore, and try to populate that from our persistence by listening
in on events MIGHT work. I am not going to try.
I still think that the library is an excellent idea, and wish that we could
get it to work. But I think I need to move on to other things to fix. This
is simply beyond me.
Any feedback?
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Quartz spike
Posted by Paul Merlin <pa...@nosphere.org>.
Once again I feel your pain Niclas. I recall coming up to the same
conclusion: Quartz is not extensible enough and tied to JDBC.
XA/UoW orchestration sounds like something that could open up for a lot
of integration, but I won't go down that road myself.
I also still think that this library is a good idea. I might take a stab
at it at some point or if the need arise in what I do.
To be continued
Niclas Hedhman a écrit :
> There are quite a few negative views of Quartz online. And possibly it
> isn't the right way to go. But I will push the branch in case someone wants
> to take a look at what I tried.
>
> Cheers
> Niclas
>
> On Tue, Dec 1, 2015 at 2:06 AM, Kent Sølvsten <ke...@gmail.com>
> wrote:
>
>> A shame :-(
>>
>> I think you should push it somewhere to preserve it for now.
>>
>> My gut feeling is that (some day) we should improve enterprise
>> integration ...
>> something involving coordination between an XA transaction and a UOW
>> - and then use a JDBCJobStore with global transactions.
>>
>> That could potentially solve a lot of problems in EE deployments - and a
>> RamJobStore might be sufficient for SE (standalone) deployments.
>>
>> But i admit, I dont know how (yet) to accomplish that integration -
>> implementing an XA resource is probably too complicated and hopefully
>> unnecessary.
>>
>> /Kent
>>
>> Den 29-11-2015 kl. 05:45 skrev Niclas Hedhman:
>>> Gang,
>>> I have now spent too many weekends on the Scheduler library.
>>>
>>> a. What we have doesn't work as expected.
>>>
>>> b. I have not been able to fix it.
>>>
>>> c. I have tried to use Quartz by re-implementing a JobStore, backed by
>>> our persistence. It is highly complicated. Quartz have not managed to
>>> separate the concerns well enough, and too much JDBC assumptions are in
>>> place. I give up on this. I can push my local branch on what I have done,
>>> if someone is interested in picking this up and run with it.
>>>
>>> d. Other hacks are possible, but simply feels utterly wrong. Having a
>> RAM
>>> based JobStore, and try to populate that from our persistence by
>> listening
>>> in on events MIGHT work. I am not going to try.
>>>
>>> I still think that the library is an excellent idea, and wish that we
>> could
>>> get it to work. But I think I need to move on to other things to fix.
>> This
>>> is simply beyond me.
>>>
>>> Any feedback?
>>>
>>> Cheers
>
>
Re: Quartz spike
Posted by Niclas Hedhman <ni...@hedhman.org>.
There are quite a few negative views of Quartz online. And possibly it
isn't the right way to go. But I will push the branch in case someone wants
to take a look at what I tried.
Cheers
Niclas
On Tue, Dec 1, 2015 at 2:06 AM, Kent Sølvsten <ke...@gmail.com>
wrote:
> A shame :-(
>
> I think you should push it somewhere to preserve it for now.
>
> My gut feeling is that (some day) we should improve enterprise
> integration ...
> something involving coordination between an XA transaction and a UOW
> - and then use a JDBCJobStore with global transactions.
>
> That could potentially solve a lot of problems in EE deployments - and a
> RamJobStore might be sufficient for SE (standalone) deployments.
>
> But i admit, I dont know how (yet) to accomplish that integration -
> implementing an XA resource is probably too complicated and hopefully
> unnecessary.
>
> /Kent
>
> Den 29-11-2015 kl. 05:45 skrev Niclas Hedhman:
> > Gang,
> > I have now spent too many weekends on the Scheduler library.
> >
> > a. What we have doesn't work as expected.
> >
> > b. I have not been able to fix it.
> >
> > c. I have tried to use Quartz by re-implementing a JobStore, backed by
> > our persistence. It is highly complicated. Quartz have not managed to
> > separate the concerns well enough, and too much JDBC assumptions are in
> > place. I give up on this. I can push my local branch on what I have done,
> > if someone is interested in picking this up and run with it.
> >
> > d. Other hacks are possible, but simply feels utterly wrong. Having a
> RAM
> > based JobStore, and try to populate that from our persistence by
> listening
> > in on events MIGHT work. I am not going to try.
> >
> > I still think that the library is an excellent idea, and wish that we
> could
> > get it to work. But I think I need to move on to other things to fix.
> This
> > is simply beyond me.
> >
> > Any feedback?
> >
> > Cheers
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Quartz spike
Posted by Kent Sølvsten <ke...@gmail.com>.
A shame :-(
I think you should push it somewhere to preserve it for now.
My gut feeling is that (some day) we should improve enterprise
integration ...
something involving coordination between an XA transaction and a UOW
- and then use a JDBCJobStore with global transactions.
That could potentially solve a lot of problems in EE deployments - and a
RamJobStore might be sufficient for SE (standalone) deployments.
But i admit, I dont know how (yet) to accomplish that integration -
implementing an XA resource is probably too complicated and hopefully
unnecessary.
/Kent
Den 29-11-2015 kl. 05:45 skrev Niclas Hedhman:
> Gang,
> I have now spent too many weekends on the Scheduler library.
>
> a. What we have doesn't work as expected.
>
> b. I have not been able to fix it.
>
> c. I have tried to use Quartz by re-implementing a JobStore, backed by
> our persistence. It is highly complicated. Quartz have not managed to
> separate the concerns well enough, and too much JDBC assumptions are in
> place. I give up on this. I can push my local branch on what I have done,
> if someone is interested in picking this up and run with it.
>
> d. Other hacks are possible, but simply feels utterly wrong. Having a RAM
> based JobStore, and try to populate that from our persistence by listening
> in on events MIGHT work. I am not going to try.
>
> I still think that the library is an excellent idea, and wish that we could
> get it to work. But I think I need to move on to other things to fix. This
> is simply beyond me.
>
> Any feedback?
>
> Cheers