Hi Romain!
Great work.
It looks much better now.
The programmatic timer is working as expected – even if a server startup is
done in the meanwhile.
The automatic timer is also working but shows a strange behavior while server
startup:
1) If no programmatic timer is available
-> automatic timer is executed two minutes after TomEE startup!
2) If a programmatic timer is defined and its trigger timestamp has not passed
while TomEE was down
-> programmatic timer is triggered correctly, but automatic timer is
executed two minutes after TomEE startup!
3) If a programmatic timer is defined and its trigger timestamp has passed
while TomEE was down
-> programmatic timer is triggered while TomEE startup (as expected), the
automatic timer is also executed immediately after TomEE startup (as expected)!
But the most important improvement: The server starts in any case, no timer
events are lost and no need to recreate the quartz tables any more.
I know, you think quartz is responsible for the two minutes delay in 1) & 2)
before automatic timer starts to fire.
But I don't think so because of the behavior in 3) where the automatic timer
starts to fire immediately after TomEE startup.
Just for curiosity:
Will the changes be integrated into a patch for TomEE 1.5.0 or only be
available with TomEE 1.5.1?
Do you already know when TomEE 1.5.1 will be available?
Best regards,
Thomas
-----
From: Romain Manni-Bucau [via OpenEJB]
[mailto:[email protected]]
Sent: Mittwoch, 14. November 2012 18:40
To: Thomas Schuler
Subject: Re: Use external database for persistent timer service
just commited some change about it,
if you can test with tmr snapshot it would be wonderful
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2012/11/14 Romain Manni-Bucau <[hidden email]>
> it is more or less what is done today, EjbTimerServiceImpl etc are
> serialized with the miminum of data saved (and their types are string
> etc...) but you can't see it in the database.
>
> The point is even if you respect it updating versions can break it.
>
> The only way to be sure the update is free is:
> 1) serialize the data as something not java dependent (here i think we
> should ask quartz)
> 2) manage missing attributes in the code when addind one
>
> We (TomEE) can manage 2 but i'd prefer to let quartz manage 1 since it is
> not directly TomEE related and other quartz usages can benefit from it
>
> wdyt?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog:
> **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
>
> 2012/11/14 tschuler <[hidden email]>
>
>> Hi Romain!
>>
>> Yes, quartz is responsible for the serialization.
>> The JobData that is serialized into the database is simply a map.
>> The data included in the map is set by the application – in your case
>> TomEE is doing it.
>> It mainly includes:
>> - EJB_TIMERS_SERVICE - an object of type
>> org.apache.openejb.core.timer.EjbTimerServiceImpl
>> - TIMER_DATA - an object of type org.apache.openejb.core.timer.TimerData
>> These are objects put to the JobData in
>> org.apache.openejb.core.timer.EjbTimerServiceImpl.schedule(TimerData
>> timerData).
>>
>> What I am concerned about is that a timer added with e.g. TomEE 1.5.0
>> cannot be executed within TomEE 1.5.1 because the deserialization fails.
>> To my way of thinking, it would be better to add only the relevant data
>> as simple data types (String, Integer, ...) to the JobData.
>> That would allow changes to the EjbTimerServiceImpl (or TimerData)
>> implementation without getting into incompatibility problems because of
>> deserialization issues within persisted timers added by a former TomEE
>> version.
>>
>> Best regards,
>> Thomas
>>
>> -----
>>
>> From: Romain Manni-Bucau [via OpenEJB] [mailto:
>> [hidden email]]
>> Sent: Samstag, 10. November 2012 10:44
>> To: Thomas Schuler
>> Subject: Re: Use external database for persistent timer service
>>
>> about serialization stuff: it is completely managed by quartz
>> (org.quartz.impl.jdbcjobstore.StdJDBCDelegate and all its children - one
>> by database type)
>>
>> we could recreate the hierarchy (you too normally configuring quartz to
>> use the context classloader and since you have not to be so generic as us
>> you can simply override serialization method in a single class) but IMO if
>> this need is relevant for you it should be pushed to quartz itself, wdyt?
>>
>> *Romain Manni-Bucau*
>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> *Blog: **http://rmannibucau.wordpress.com/*<
>> http://rmannibucau.wordpress.com/>
>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> *Github: https://github.com/rmannibucau*
>>
>>
>>
>>
>> 2012/11/9 Romain Manni-Bucau <[hidden email]>
>>
>> > I pushed some stuff yesterday about 2 (well can be linked even if not
>> > direct) so it should be in the snapshot
>> > Le 9 nov. 2012 13:16, "tschuler" <[hidden email]> a écrit :
>> >
>> > Hi Romain!
>> >>
>> >> About 1: It may be a config issue, but I don't think so - doesn't
>> matter
>> >> right now.
>> >> About 2: If you have a solution for it, please let me know. Would be
>> >> included in a future snapshot, I think?
>> >> About 3: We need to be sure that timer issues using e.g. the actual
>> TomEE
>> >> version can be executed using the next TomEE version.
>> >> As there are serialized OpenEJB classes in the quartz
>> >> database, they may be incompatible with the class definition included
>> in a
>> >> future TomEE version.
>> >>
>> >> Best regards,
>> >> Thomas
>> >>
>> >>
>> >> From: Romain Manni-Bucau [via OpenEJB] [mailto:
>> >> [hidden email]]
>> >> Sent: Donnerstag, 8. November 2012 22:38
>> >> To: Thomas Schuler
>> >> Subject: Re: Use external database for persistent timer service
>> >>
>> >> about 1: maybe just a quartz config
>> >> about 2: looking into it, think i got why but thinking to the best
>> >> solution*
>> >> about 3: we can store it as we want. That said not sure it'd be used,
>> if
>> >> you change your tomee instance you often reset some datas (and i think
>> >> these timers can be resetted in such a case, no?)
>> >>
>> >> *Romain Manni-Bucau*
>> >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>> >> *Blog: **http://rmannibucau.wordpress.com/*<
>> >> http://rmannibucau.wordpress.com/>
>> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> >> *Github: https://github.com/rmannibucau*
>> >>
>> >>
>> >>
>> >>
>> >> 2012/11/8 tschuler <[hidden
>> >> email]</user/SendEmail.jtp?type=node&node=4658490&i=0>>
>> >>
>> >> > Hi!
>> >> >
>> >> > I tried todays snapshot and it worked better if TomEE is running all
>> the
>> >> > time.
>> >> > But in case of TomEE restart a few errors happen for persisted
>> timers.
>> >> >
>> >> > 1) automatic timeout:
>> >> > It takes two minutes until the timer fires again
>> >> >
>> >> > 08.11.2012 14:28:46 org.apache.catalina.startup.Catalina
>> start
>> >> > INFO: Server startup in 2357 ms
>> >> > 08.11.2012 14:29:45
>> org.quartz.impl.jdbcjobstore.JobStoreSupport
>> >> > logWarnIfNonZero
>> >> > INFO: ClusterManager: detected 1 failed or restarted
>> instances.
>> >> > 08.11.2012 14:29:45
>> org.quartz.impl.jdbcjobstore.JobStoreSupport
>> >> > clusterRecover
>> >> > INFO: ClusterManager: Scanning for instance
>> >> > "DE064071352380642408"'s
>> >> > failed in-progress jobs.
>> >> > 08.11.2012 14:29:45
>> org.quartz.impl.jdbcjobstore.JobStoreSupport
>> >> > logWarnIfNonZero
>> >> > INFO: ClusterManager: ......Freed 1 acquired trigger(s).
>> >> > 08.11.2012 14:30:45
>> org.quartz.impl.jdbcjobstore.JobStoreSupport
>> >> > recoverMisfiredJobs
>> >> > INFO: Handling 1 trigger(s) that missed their scheduled
>> >> fire-time.
>> >> > 08.11.2012 14:30:45
>> timerPersisted.server.SchedulerBeanAutomated
>> >> > automaticTimeout
>> >> > INFO: Automatic timeout occured
>> >> >
>> >> > 2) automatic and programmatic timeouts:
>> >> > TomEE kill prevented the execution of five programmatic timeouts,
>> >> while
>> >> > server restart the first programmatic timeout causes an error and is
>> >> never
>> >> > executed
>> >> >
>> >> > INFO: OpenWebBeans Container has started, it took 10 ms.
>> >> > 08.11.2012 16:59:02
>> >> > org.apache.openejb.core.timer.EjbTimerServiceImpl ejbTimeout
>> >> > WARNUNG: Exception from ejbTimeout on SchedulerBeanPersisted
>> >> > org.apache.openejb.OpenEJBException: Deployment does not
>> exist
>> >> in
>> >> > this container. Deployment(id='SchedulerBeanPersisted'),
>> >> Container(id='My
>> >> > Singleton Container')
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.singleton.SingletonContainer.invoke(SingletonContainer.java:180)
>>
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:552)
>>
>> >> > at
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
>> >> > at
>> org.quartz.core.JobRunShell.run(JobRunShell.java:213)
>> >> > at
>> >> >
>> >> >
>> >>
>> org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
>>
>> >> > 08.11.2012 16:59:02
>> >> org.apache.openejb.assembler.classic.Assembler
>> >> > createApplication
>> >> > INFO: Created Ejb(deployment-id=SchedulerBeanAutomated,
>> >> > ejb-name=SchedulerBeanAutomated, container=My Singleton Container)
>> >> > 08.11.2012 16:59:02
>> >> > org.apache.openejb.core.timer.EjbTimerServiceImpl ejbTimeout
>> >> > WARNUNG: Exception from ejbTimeout on SchedulerBeanPersisted
>> >> > org.apache.openejb.OpenEJBException: Deployment does not
>> exist
>> >> in
>> >> > this container. Deployment(id='SchedulerBeanPersisted'),
>> >> Container(id='My
>> >> > Singleton Container')
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.singleton.SingletonContainer.invoke(SingletonContainer.java:180)
>>
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:552)
>>
>> >> > at
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
>> >> > at
>> org.quartz.core.JobRunShell.run(JobRunShell.java:213)
>> >> > at
>> >> >
>> >> >
>> >>
>> org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
>>
>> >> > 08.11.2012 16:59:02
>> >> > org.apache.openejb.core.timer.EjbTimerServiceImpl ejbTimeout
>> >> > WARNUNG: Exception from ejbTimeout on SchedulerBeanPersisted
>> >> > org.apache.openejb.OpenEJBException: Deployment does not
>> exist
>> >> in
>> >> > this container. Deployment(id='SchedulerBeanPersisted'),
>> >> Container(id='My
>> >> > Singleton Container')
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.singleton.SingletonContainer.invoke(SingletonContainer.java:180)
>>
>> >> > at
>> >> >
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:552)
>>
>> >> > at
>> >> >
>> >>
>> org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
>> >> > at
>> org.quartz.core.JobRunShell.run(JobRunShell.java:213)
>> >> > at
>> >> >
>> >> >
>> >>
>> org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
>>
>> >> > 08.11.2012 16:59:02
>> >> > org.apache.openejb.core.timer.EjbTimerServiceImpl ejbTimeout
>> >> > WARNUNG: Failed to execute ejbTimeout on
>> SchedulerBeanPersisted
>> >> > successfully within 1 attempts
>> >> > 08.11.2012 16:59:02
>> >> org.apache.openejb.assembler.classic.Assembler
>> >> > createApplication
>> >> > INFO: Created Ejb(deployment-id=SchedulerBeanPersisted,
>> >> > ejb-name=SchedulerBeanPersisted, container=My Singleton Container)
>> >> > 08.11.2012 16:59:02
>> >> org.apache.openejb.assembler.classic.Assembler
>> >> > createApplication
>> >> > INFO: Started Ejb(deployment-id=SchedulerBeanAutomated,
>> >> > ejb-name=SchedulerBeanAutomated, container=My Singleton Container)
>> >> > 08.11.2012 16:59:02
>> >> org.apache.openejb.assembler.classic.Assembler
>> >> > createApplication
>> >> > INFO: Started Ejb(deployment-id=SchedulerBeanPersisted,
>> >> > ejb-name=SchedulerBeanPersisted, container=My Singleton Container)
>> >> > 08.11.2012 16:59:02
>> >> org.apache.openejb.assembler.classic.Assembler
>> >> > createApplication
>> >> > INFO: Deployed
>> >> >
>> >> >
>> >>
>> Application(path=C:\Java\tomee-examples\tomee-timerPersisted\webapps\timerPersisted)
>>
>> >> > 08.11.2012 16:59:02
>> timerPersisted.server.SchedulerBeanPersisted
>> >> > programmaticTimeout
>> >> > INFO: Programmatic timeout occurred.
>> >> >
>> >> > 3) Having a look into the quartz database tables, I can see that
>> >> JOB_DATA
>> >> > column of table QRTZ_TRIGGERS includes the, let me call it timer
>> >> context.
>> >> > This timer context includes serialized objects.
>> >> > What I am wondering about is how you can garantee that the timer
>> >> events
>> >> > can be executed with an updated TomEE version that may include an
>> >> update of
>> >> > the serialzed objects?
>> >> >
>> >> > Best regards,
>> >> > Thomas
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > View this message in context:
>> >> >
>> >>
>> http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658484.html
>> >> > Sent from the OpenEJB User mailing list archive at Nabble.com.
>> >> >
>> >>
>> >> ________________________________
>> >> If you reply to this email, your message will be added to the
>> discussion
>> >> below:
>> >>
>> >>
>> http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658490.html
>> >> To unsubscribe from Use external database for persistent timer service,
>> >> click here<
>> >> >.
>> >> NAML<
>> >>
>> http://openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658495.html
>> >> Sent from the OpenEJB User mailing list archive at Nabble.com.
>> >
>> >
>>
>> ________________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658507.html
>> To unsubscribe from Use external database for persistent timer service,
>> click here.
>> NAML
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658607.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>
>
________________________________________
If you reply to this email, your message will be added to the discussion below:
http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658611.html
To unsubscribe from Use external database for persistent timer service, click
here.
NAML
--
View this message in context:
http://openejb.979440.n4.nabble.com/Use-external-database-for-persistent-timer-service-tp4658321p4658626.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
