You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Enrico Olivelli <eo...@gmail.com> on 2012/08/21 18:58:57 UTC
Handle undeployed app with clustered Quartz scheduler
When I undeploy an app with an EJB timer, the trigger is not removed, so
when quartz tries to reload the trigger from DB gets a NullPointer exception
I suggest:
- to remove triggers/jobdata from Quartz on "undeploy"
- to handle this situation, maybe tring to remove the failing trigger
(or give quartz a "noop" task?!?!?)
rave: MisfireHandler: Error handling misfires: Couldn't retrieve
trigger: null
org.quartz.JobPersistenceException: Couldn't retrieve trigger: null [See
nested exception: java.lang.NullPointerException]
at
org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveTrigger(JobStoreSupport.java:1524)
at
org.quartz.impl.jdbcjobstore.JobStoreSupport.recoverMisfiredJobs(JobStoreSupport.java:968)
at
org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3187)
at
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3947)
at
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3968)
Caused by: java.lang.NullPointerException
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.getDefaultScheduler(EjbTimerServiceImpl.java:121)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.readObject(EjbTimerServiceImpl.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i think so too
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/23 Enrico Olivelli <eo...@gmail.com>
> you added org.quartz.scheduler.jmx.**export=true
> then Quartz published a MBean for each Scheduler (instanceName)
>
> I this is enough to cleanup "orphan" triggers
> thanks
>
>
> Il 22/08/2012 19:19, Romain Manni-Bucau ha scritto:
>
>> getting the HEAD you should get some info through JMX
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau*
>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>> *
>>
>>
>>
>>
>> 2012/8/22 Romain Manni-Bucau <rm...@gmail.com>
>>
>> great to hear you like tomee :)
>>>
>>> if you want to write docs please do, we'll be happy to integrate them in
>>> our doc pages :)
>>>
>>> the comman dis not bad and we have already some command pattern (for
>>> tomee
>>> maven plugin, karafee and ssh console), could even be done through JMX i
>>> think, it is clearly something to think a bit more but can be a great
>>> added
>>> value
>>>
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau*
>>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/22 Enrico Olivelli <eo...@gmail.com>
>>>
>>> I did a build on trunk and now undeploy of triggers works great
>>>>
>>>> I tested a scenario with two apps:
>>>> - one uses the "default scheduler"
>>>> - one uses a custom scheduler defined in WEB-INF/application.conf
>>>> When I undeploy one app triggers are deleted from the "right" db and the
>>>> other scheduler continues to work
>>>>
>>>> This feature was important because when you reload your app (during
>>>> development) you would like
>>>> - to rename your EJBTimered-bean
>>>> - to change automatic timers defined with @Schedule (before this
>>>> enhancement if you declared your timer to be executed once a minute, you
>>>> could not change it without dropping/recreating quartz tables)
>>>>
>>>> For me it's all OK about Quartz now
>>>> Some docs/examples have to be written because configuring a
>>>> persistent/clustered Quartz is not very simple (I can write it)
>>>>
>>>> I'm coming from GF3, I think that now TomEE 1.1 is better than it !!!
>>>> http://docs.oracle.com/cd/****E18930_01/html/821-2418/beahw.****html<http://docs.oracle.com/cd/**E18930_01/html/821-2418/beahw.**html>
>>>> <http://docs.oracle.com/**cd/E18930_01/html/821-2418/**beahw.html<http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html>
>>>> >
>>>>
>>>>
>>>> From the GF command line you can list timers
>>>> http://docs.oracle.com/cd/****E19798-01/821-1751/giojd/****index.html<http://docs.oracle.com/cd/**E19798-01/821-1751/giojd/**index.html>
>>>> <http://docs.oracle.**com/cd/E19798-01/821-1751/**giojd/index.html<http://docs.oracle.com/cd/E19798-01/821-1751/giojd/index.html>
>>>> >
>>>>
>>>> maybe it would be usefull to have such command and a command to erase a
>>>> trigger (because undeploy of the trigger failed and there is no way to
>>>> drop
>>>> it)
>>>> but I really do not need these commands
>>>>
>>>> great job !
>>>> thank you
>>>> - Enrico
>>>>
>>>>
>>>> Il 21/08/2012 20:25, Romain Manni-Bucau ha scritto:
>>>>
>>>> unscheduled the trigger job however not sure it is the only cause.
>>>>>
>>>>> btw your lines are no more up to date i think so not sure of the cause,
>>>>>
>>>>> can you give it try with the up to date snapshot please?
>>>>>
>>>>> *Romain Manni-Bucau*
>>>>> *Twitter: @rmannibucau*
>>>>> *Blog: http://rmannibucau.wordpress.****com<http://rmannibucau.**
>>>>> wordpress.com <http://rmannibucau.wordpress.com>>
>>>>>
>>>>> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2012/8/21 Enrico Olivelli <eo...@gmail.com>
>>>>>
>>>>> When I undeploy an app with an EJB timer, the trigger is not
>>>>> removed, so
>>>>>
>>>>>> when quartz tries to reload the trigger from DB gets a NullPointer
>>>>>> exception
>>>>>> I suggest:
>>>>>> - to remove triggers/jobdata from Quartz on "undeploy"
>>>>>> - to handle this situation, maybe tring to remove the failing trigger
>>>>>> (or
>>>>>> give quartz a "noop" task?!?!?)
>>>>>>
>>>>>>
>>>>>> rave: MisfireHandler: Error handling misfires: Couldn't retrieve
>>>>>> trigger:
>>>>>> null
>>>>>> org.quartz.******JobPersistenceException: Couldn't retrieve trigger:
>>>>>> null
>>>>>> [See nested exception: java.lang.******NullPointerException]
>>>>>> at org.quartz.impl.jdbcjobstore.******JobStoreSupport.****
>>>>>> retrieveTrigger(**
>>>>>> JobStoreSupport.java:1524)
>>>>>> at org.quartz.impl.jdbcjobstore.******JobStoreSupport.**
>>>>>> recoverMisfiredJobs(******JobStoreSupport.java:968)
>>>>>> at org.quartz.impl.jdbcjobstore.******JobStoreSupport.****
>>>>>> doRecoverMisfires(
>>>>>> **JobStoreSupport.java:3187)
>>>>>> at org.quartz.impl.jdbcjobstore.******JobStoreSupport$**
>>>>>> MisfireHandler.manage(******JobStoreSupport.java:3947)
>>>>>> at org.quartz.impl.jdbcjobstore.******JobStoreSupport$**
>>>>>> MisfireHandler.run(******JobStoreSupport.java:3968)
>>>>>> Caused by: java.lang.NullPointerException
>>>>>> at org.apache.openejb.core.timer.******EjbTimerServiceImpl.**
>>>>>> getDefaultScheduler(******EjbTimerServiceImpl.java:121)
>>>>>> at org.apache.openejb.core.timer.******EjbTimerServiceImpl.****
>>>>>> readObject(**
>>>>>> EjbTimerServiceImpl.java:117)
>>>>>> at sun.reflect.******NativeMethodAccessorImpl.******
>>>>>> invoke0(Native
>>>>>> Method)
>>>>>> at sun.reflect.******NativeMethodAccessorImpl.******invoke(**
>>>>>> NativeMethodAccessorImpl.java:******57)
>>>>>> at sun.reflect.******DelegatingMethodAccessorImpl.***
>>>>>> ***invoke(**
>>>>>> DelegatingMethodAccessorImpl.******java:43)
>>>>>>
>>>>>>
>>>>>>
>
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Enrico Olivelli <eo...@gmail.com>.
you added org.quartz.scheduler.jmx.export=true
then Quartz published a MBean for each Scheduler (instanceName)
I this is enough to cleanup "orphan" triggers
thanks
Il 22/08/2012 19:19, Romain Manni-Bucau ha scritto:
> getting the HEAD you should get some info through JMX
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/8/22 Romain Manni-Bucau <rm...@gmail.com>
>
>> great to hear you like tomee :)
>>
>> if you want to write docs please do, we'll be happy to integrate them in
>> our doc pages :)
>>
>> the comman dis not bad and we have already some command pattern (for tomee
>> maven plugin, karafee and ssh console), could even be done through JMX i
>> think, it is clearly something to think a bit more but can be a great added
>> value
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau*
>> *Blog: http://rmannibucau.wordpress.com*
>>
>>
>>
>>
>> 2012/8/22 Enrico Olivelli <eo...@gmail.com>
>>
>>> I did a build on trunk and now undeploy of triggers works great
>>>
>>> I tested a scenario with two apps:
>>> - one uses the "default scheduler"
>>> - one uses a custom scheduler defined in WEB-INF/application.conf
>>> When I undeploy one app triggers are deleted from the "right" db and the
>>> other scheduler continues to work
>>>
>>> This feature was important because when you reload your app (during
>>> development) you would like
>>> - to rename your EJBTimered-bean
>>> - to change automatic timers defined with @Schedule (before this
>>> enhancement if you declared your timer to be executed once a minute, you
>>> could not change it without dropping/recreating quartz tables)
>>>
>>> For me it's all OK about Quartz now
>>> Some docs/examples have to be written because configuring a
>>> persistent/clustered Quartz is not very simple (I can write it)
>>>
>>> I'm coming from GF3, I think that now TomEE 1.1 is better than it !!!
>>> http://docs.oracle.com/cd/**E18930_01/html/821-2418/beahw.**html<http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html>
>>>
>>> From the GF command line you can list timers
>>> http://docs.oracle.com/cd/**E19798-01/821-1751/giojd/**index.html<http://docs.oracle.com/cd/E19798-01/821-1751/giojd/index.html>
>>> maybe it would be usefull to have such command and a command to erase a
>>> trigger (because undeploy of the trigger failed and there is no way to drop
>>> it)
>>> but I really do not need these commands
>>>
>>> great job !
>>> thank you
>>> - Enrico
>>>
>>>
>>> Il 21/08/2012 20:25, Romain Manni-Bucau ha scritto:
>>>
>>>> unscheduled the trigger job however not sure it is the only cause.
>>>>
>>>> btw your lines are no more up to date i think so not sure of the cause,
>>>>
>>>> can you give it try with the up to date snapshot please?
>>>>
>>>> *Romain Manni-Bucau*
>>>> *Twitter: @rmannibucau*
>>>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> 2012/8/21 Enrico Olivelli <eo...@gmail.com>
>>>>
>>>> When I undeploy an app with an EJB timer, the trigger is not removed, so
>>>>> when quartz tries to reload the trigger from DB gets a NullPointer
>>>>> exception
>>>>> I suggest:
>>>>> - to remove triggers/jobdata from Quartz on "undeploy"
>>>>> - to handle this situation, maybe tring to remove the failing trigger
>>>>> (or
>>>>> give quartz a "noop" task?!?!?)
>>>>>
>>>>>
>>>>> rave: MisfireHandler: Error handling misfires: Couldn't retrieve
>>>>> trigger:
>>>>> null
>>>>> org.quartz.****JobPersistenceException: Couldn't retrieve trigger: null
>>>>> [See nested exception: java.lang.****NullPointerException]
>>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>>>> retrieveTrigger(**
>>>>> JobStoreSupport.java:1524)
>>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.**
>>>>> recoverMisfiredJobs(****JobStoreSupport.java:968)
>>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>>>> doRecoverMisfires(
>>>>> **JobStoreSupport.java:3187)
>>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>>>> MisfireHandler.manage(****JobStoreSupport.java:3947)
>>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>>>> MisfireHandler.run(****JobStoreSupport.java:3968)
>>>>> Caused by: java.lang.NullPointerException
>>>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.**
>>>>> getDefaultScheduler(****EjbTimerServiceImpl.java:121)
>>>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.****
>>>>> readObject(**
>>>>> EjbTimerServiceImpl.java:117)
>>>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke0(Native
>>>>> Method)
>>>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke(**
>>>>> NativeMethodAccessorImpl.java:****57)
>>>>> at sun.reflect.****DelegatingMethodAccessorImpl.****invoke(**
>>>>> DelegatingMethodAccessorImpl.****java:43)
>>>>>
>>>>>
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
getting the HEAD you should get some info through JMX
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/22 Romain Manni-Bucau <rm...@gmail.com>
> great to hear you like tomee :)
>
> if you want to write docs please do, we'll be happy to integrate them in
> our doc pages :)
>
> the comman dis not bad and we have already some command pattern (for tomee
> maven plugin, karafee and ssh console), could even be done through JMX i
> think, it is clearly something to think a bit more but can be a great added
> value
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/8/22 Enrico Olivelli <eo...@gmail.com>
>
>> I did a build on trunk and now undeploy of triggers works great
>>
>> I tested a scenario with two apps:
>> - one uses the "default scheduler"
>> - one uses a custom scheduler defined in WEB-INF/application.conf
>> When I undeploy one app triggers are deleted from the "right" db and the
>> other scheduler continues to work
>>
>> This feature was important because when you reload your app (during
>> development) you would like
>> - to rename your EJBTimered-bean
>> - to change automatic timers defined with @Schedule (before this
>> enhancement if you declared your timer to be executed once a minute, you
>> could not change it without dropping/recreating quartz tables)
>>
>> For me it's all OK about Quartz now
>> Some docs/examples have to be written because configuring a
>> persistent/clustered Quartz is not very simple (I can write it)
>>
>> I'm coming from GF3, I think that now TomEE 1.1 is better than it !!!
>> http://docs.oracle.com/cd/**E18930_01/html/821-2418/beahw.**html<http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html>
>>
>> From the GF command line you can list timers
>> http://docs.oracle.com/cd/**E19798-01/821-1751/giojd/**index.html<http://docs.oracle.com/cd/E19798-01/821-1751/giojd/index.html>
>> maybe it would be usefull to have such command and a command to erase a
>> trigger (because undeploy of the trigger failed and there is no way to drop
>> it)
>> but I really do not need these commands
>>
>> great job !
>> thank you
>> - Enrico
>>
>>
>> Il 21/08/2012 20:25, Romain Manni-Bucau ha scritto:
>>
>>> unscheduled the trigger job however not sure it is the only cause.
>>>
>>> btw your lines are no more up to date i think so not sure of the cause,
>>>
>>> can you give it try with the up to date snapshot please?
>>>
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau*
>>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/21 Enrico Olivelli <eo...@gmail.com>
>>>
>>> When I undeploy an app with an EJB timer, the trigger is not removed, so
>>>> when quartz tries to reload the trigger from DB gets a NullPointer
>>>> exception
>>>> I suggest:
>>>> - to remove triggers/jobdata from Quartz on "undeploy"
>>>> - to handle this situation, maybe tring to remove the failing trigger
>>>> (or
>>>> give quartz a "noop" task?!?!?)
>>>>
>>>>
>>>> rave: MisfireHandler: Error handling misfires: Couldn't retrieve
>>>> trigger:
>>>> null
>>>> org.quartz.****JobPersistenceException: Couldn't retrieve trigger: null
>>>> [See nested exception: java.lang.****NullPointerException]
>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>>> retrieveTrigger(**
>>>> JobStoreSupport.java:1524)
>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.**
>>>> recoverMisfiredJobs(****JobStoreSupport.java:968)
>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>>> doRecoverMisfires(
>>>> **JobStoreSupport.java:3187)
>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>>> MisfireHandler.manage(****JobStoreSupport.java:3947)
>>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>>> MisfireHandler.run(****JobStoreSupport.java:3968)
>>>> Caused by: java.lang.NullPointerException
>>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.**
>>>> getDefaultScheduler(****EjbTimerServiceImpl.java:121)
>>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.****
>>>> readObject(**
>>>> EjbTimerServiceImpl.java:117)
>>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke0(Native
>>>> Method)
>>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke(**
>>>> NativeMethodAccessorImpl.java:****57)
>>>> at sun.reflect.****DelegatingMethodAccessorImpl.****invoke(**
>>>> DelegatingMethodAccessorImpl.****java:43)
>>>>
>>>>
>>
>
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
great to hear you like tomee :)
if you want to write docs please do, we'll be happy to integrate them in
our doc pages :)
the comman dis not bad and we have already some command pattern (for tomee
maven plugin, karafee and ssh console), could even be done through JMX i
think, it is clearly something to think a bit more but can be a great added
value
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/22 Enrico Olivelli <eo...@gmail.com>
> I did a build on trunk and now undeploy of triggers works great
>
> I tested a scenario with two apps:
> - one uses the "default scheduler"
> - one uses a custom scheduler defined in WEB-INF/application.conf
> When I undeploy one app triggers are deleted from the "right" db and the
> other scheduler continues to work
>
> This feature was important because when you reload your app (during
> development) you would like
> - to rename your EJBTimered-bean
> - to change automatic timers defined with @Schedule (before this
> enhancement if you declared your timer to be executed once a minute, you
> could not change it without dropping/recreating quartz tables)
>
> For me it's all OK about Quartz now
> Some docs/examples have to be written because configuring a
> persistent/clustered Quartz is not very simple (I can write it)
>
> I'm coming from GF3, I think that now TomEE 1.1 is better than it !!!
> http://docs.oracle.com/cd/**E18930_01/html/821-2418/beahw.**html<http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html>
>
> From the GF command line you can list timers
> http://docs.oracle.com/cd/**E19798-01/821-1751/giojd/**index.html<http://docs.oracle.com/cd/E19798-01/821-1751/giojd/index.html>
> maybe it would be usefull to have such command and a command to erase a
> trigger (because undeploy of the trigger failed and there is no way to drop
> it)
> but I really do not need these commands
>
> great job !
> thank you
> - Enrico
>
>
> Il 21/08/2012 20:25, Romain Manni-Bucau ha scritto:
>
>> unscheduled the trigger job however not sure it is the only cause.
>>
>> btw your lines are no more up to date i think so not sure of the cause,
>>
>> can you give it try with the up to date snapshot please?
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau*
>> *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>> *
>>
>>
>>
>>
>> 2012/8/21 Enrico Olivelli <eo...@gmail.com>
>>
>> When I undeploy an app with an EJB timer, the trigger is not removed, so
>>> when quartz tries to reload the trigger from DB gets a NullPointer
>>> exception
>>> I suggest:
>>> - to remove triggers/jobdata from Quartz on "undeploy"
>>> - to handle this situation, maybe tring to remove the failing trigger (or
>>> give quartz a "noop" task?!?!?)
>>>
>>>
>>> rave: MisfireHandler: Error handling misfires: Couldn't retrieve trigger:
>>> null
>>> org.quartz.****JobPersistenceException: Couldn't retrieve trigger: null
>>> [See nested exception: java.lang.****NullPointerException]
>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>> retrieveTrigger(**
>>> JobStoreSupport.java:1524)
>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.**
>>> recoverMisfiredJobs(****JobStoreSupport.java:968)
>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport.****
>>> doRecoverMisfires(
>>> **JobStoreSupport.java:3187)
>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>> MisfireHandler.manage(****JobStoreSupport.java:3947)
>>> at org.quartz.impl.jdbcjobstore.****JobStoreSupport$**
>>> MisfireHandler.run(****JobStoreSupport.java:3968)
>>> Caused by: java.lang.NullPointerException
>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.**
>>> getDefaultScheduler(****EjbTimerServiceImpl.java:121)
>>> at org.apache.openejb.core.timer.****EjbTimerServiceImpl.****
>>> readObject(**
>>> EjbTimerServiceImpl.java:117)
>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke0(Native
>>> Method)
>>> at sun.reflect.****NativeMethodAccessorImpl.****invoke(**
>>> NativeMethodAccessorImpl.java:****57)
>>> at sun.reflect.****DelegatingMethodAccessorImpl.****invoke(**
>>> DelegatingMethodAccessorImpl.****java:43)
>>>
>>>
>
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Enrico Olivelli <eo...@gmail.com>.
I did a build on trunk and now undeploy of triggers works great
I tested a scenario with two apps:
- one uses the "default scheduler"
- one uses a custom scheduler defined in WEB-INF/application.conf
When I undeploy one app triggers are deleted from the "right" db and the
other scheduler continues to work
This feature was important because when you reload your app (during
development) you would like
- to rename your EJBTimered-bean
- to change automatic timers defined with @Schedule (before this
enhancement if you declared your timer to be executed once a minute, you
could not change it without dropping/recreating quartz tables)
For me it's all OK about Quartz now
Some docs/examples have to be written because configuring a
persistent/clustered Quartz is not very simple (I can write it)
I'm coming from GF3, I think that now TomEE 1.1 is better than it !!!
http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html
From the GF command line you can list timers
http://docs.oracle.com/cd/E19798-01/821-1751/giojd/index.html
maybe it would be usefull to have such command and a command to erase a
trigger (because undeploy of the trigger failed and there is no way to
drop it)
but I really do not need these commands
great job !
thank you
- Enrico
Il 21/08/2012 20:25, Romain Manni-Bucau ha scritto:
> unscheduled the trigger job however not sure it is the only cause.
>
> btw your lines are no more up to date i think so not sure of the cause,
>
> can you give it try with the up to date snapshot please?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/8/21 Enrico Olivelli <eo...@gmail.com>
>
>> When I undeploy an app with an EJB timer, the trigger is not removed, so
>> when quartz tries to reload the trigger from DB gets a NullPointer exception
>> I suggest:
>> - to remove triggers/jobdata from Quartz on "undeploy"
>> - to handle this situation, maybe tring to remove the failing trigger (or
>> give quartz a "noop" task?!?!?)
>>
>>
>> rave: MisfireHandler: Error handling misfires: Couldn't retrieve trigger:
>> null
>> org.quartz.**JobPersistenceException: Couldn't retrieve trigger: null
>> [See nested exception: java.lang.**NullPointerException]
>> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**retrieveTrigger(**
>> JobStoreSupport.java:1524)
>> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**
>> recoverMisfiredJobs(**JobStoreSupport.java:968)
>> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**doRecoverMisfires(
>> **JobStoreSupport.java:3187)
>> at org.quartz.impl.jdbcjobstore.**JobStoreSupport$**
>> MisfireHandler.manage(**JobStoreSupport.java:3947)
>> at org.quartz.impl.jdbcjobstore.**JobStoreSupport$**
>> MisfireHandler.run(**JobStoreSupport.java:3968)
>> Caused by: java.lang.NullPointerException
>> at org.apache.openejb.core.timer.**EjbTimerServiceImpl.**
>> getDefaultScheduler(**EjbTimerServiceImpl.java:121)
>> at org.apache.openejb.core.timer.**EjbTimerServiceImpl.**readObject(**
>> EjbTimerServiceImpl.java:117)
>> at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
>> at sun.reflect.**NativeMethodAccessorImpl.**invoke(**
>> NativeMethodAccessorImpl.java:**57)
>> at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
>> DelegatingMethodAccessorImpl.**java:43)
>>
Re: Handle undeployed app with clustered Quartz scheduler
Posted by Romain Manni-Bucau <rm...@gmail.com>.
unscheduled the trigger job however not sure it is the only cause.
btw your lines are no more up to date i think so not sure of the cause,
can you give it try with the up to date snapshot please?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Enrico Olivelli <eo...@gmail.com>
> When I undeploy an app with an EJB timer, the trigger is not removed, so
> when quartz tries to reload the trigger from DB gets a NullPointer exception
> I suggest:
> - to remove triggers/jobdata from Quartz on "undeploy"
> - to handle this situation, maybe tring to remove the failing trigger (or
> give quartz a "noop" task?!?!?)
>
>
> rave: MisfireHandler: Error handling misfires: Couldn't retrieve trigger:
> null
> org.quartz.**JobPersistenceException: Couldn't retrieve trigger: null
> [See nested exception: java.lang.**NullPointerException]
> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**retrieveTrigger(**
> JobStoreSupport.java:1524)
> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**
> recoverMisfiredJobs(**JobStoreSupport.java:968)
> at org.quartz.impl.jdbcjobstore.**JobStoreSupport.**doRecoverMisfires(
> **JobStoreSupport.java:3187)
> at org.quartz.impl.jdbcjobstore.**JobStoreSupport$**
> MisfireHandler.manage(**JobStoreSupport.java:3947)
> at org.quartz.impl.jdbcjobstore.**JobStoreSupport$**
> MisfireHandler.run(**JobStoreSupport.java:3968)
> Caused by: java.lang.NullPointerException
> at org.apache.openejb.core.timer.**EjbTimerServiceImpl.**
> getDefaultScheduler(**EjbTimerServiceImpl.java:121)
> at org.apache.openejb.core.timer.**EjbTimerServiceImpl.**readObject(**
> EjbTimerServiceImpl.java:117)
> at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
> at sun.reflect.**NativeMethodAccessorImpl.**invoke(**
> NativeMethodAccessorImpl.java:**57)
> at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
> DelegatingMethodAccessorImpl.**java:43)
>