You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Lars-Fredrik Smedberg <it...@gmail.com> on 2015/04/18 16:36:49 UTC
Long running background tasks using Java EE 6
Hi
I need to run a background task that will poll messages from a
BlockingQueue, aggregate data (to some degree) and at regular intervals
write the data to a file (append to a file).
Each appserver instance will write to its own file so there is no need to
sync within a cluster or similar...
I guess I could at startup create my own thread and peek the queue etc...
but if I would keep it more strict Java EE 6 and also need access to
@ApplicationScoped beans then I guess I could either use a one-off
programmatic EJB timer or calling an @Asynchronous EJB methos
(started/called from a @Singleton @Startup... EJB).
What is the preferred approach you would use?
Regards
LF
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Carlos: what is TimerService excepted a standard API for quartz? ;)
Le 19 avr. 2015 13:57, "cchacin" <cc...@gmail.com> a écrit :
> Maybe you can use quartz.
>
> http://quartz-scheduler.org/
>
> On Sat, Apr 18, 2015, 8:01 AM Lars-Fredrik Smedberg [via TomEE & OpenEJB] <
> ml-node+s979440n4674476h14@n4.nabble.com> wrote:
>
> > Understand that... Unfortunately we are running Java EE6 in production
> and
> > cannot pull it in as a third party prod for various reasons
> > On Apr 18, 2015 4:58 PM, <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4674476&i=0>> wrote:
> >
> > > I am very happy with jbatch aka batchee.
> > >
> > > Skickat från min iPhone
> > >
> > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4674476&i=1>>:
> > > >
> > > > Hi
> > > >
> > > > I need to run a background task that will poll messages from a
> > > > BlockingQueue, aggregate data (to some degree) and at regular
> > intervals
> > > > write the data to a file (append to a file).
> > > >
> > > > Each appserver instance will write to its own file so there is no
> need
> > to
> > > > sync within a cluster or similar...
> > > >
> > > > I guess I could at startup create my own thread and peek the queue
> > etc...
> > > > but if I would keep it more strict Java EE 6 and also need access to
> > > > @ApplicationScoped beans then I guess I could either use a one-off
> > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > (started/called from a @Singleton @Startup... EJB).
> > > >
> > > > What is the preferred approach you would use?
> > > >
> > > > Regards
> > > > LF
> > >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/Long-running-background-tasks-using-Java-EE-6-tp4674474p4674476.html
> > To start a new topic under TomEE Users, email
> > ml-node+s979440n979441h29@n4.nabble.com
> > To unsubscribe from TomEE Users, click here
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=979441&code=Y2NoYWNpbkBnbWFpbC5jb218OTc5NDQxfDE2NzcwMDYzOTY=
> >
> > .
> > NAML
> > <
> http://tomee-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
> >
> >
>
>
>
>
> -----
> Carlos Chacin
> http://github.com/cchacin
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Long-running-background-tasks-using-Java-EE-6-tp4674474p4674477.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
Re: Long running background tasks using Java EE 6
Posted by cchacin <cc...@gmail.com>.
Maybe you can use quartz.
http://quartz-scheduler.org/
On Sat, Apr 18, 2015, 8:01 AM Lars-Fredrik Smedberg [via TomEE & OpenEJB] <
ml-node+s979440n4674476h14@n4.nabble.com> wrote:
> Understand that... Unfortunately we are running Java EE6 in production and
> cannot pull it in as a third party prod for various reasons
> On Apr 18, 2015 4:58 PM, <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4674476&i=0>> wrote:
>
> > I am very happy with jbatch aka batchee.
> >
> > Skickat från min iPhone
> >
> > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4674476&i=1>>:
> > >
> > > Hi
> > >
> > > I need to run a background task that will poll messages from a
> > > BlockingQueue, aggregate data (to some degree) and at regular
> intervals
> > > write the data to a file (append to a file).
> > >
> > > Each appserver instance will write to its own file so there is no need
> to
> > > sync within a cluster or similar...
> > >
> > > I guess I could at startup create my own thread and peek the queue
> etc...
> > > but if I would keep it more strict Java EE 6 and also need access to
> > > @ApplicationScoped beans then I guess I could either use a one-off
> > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > (started/called from a @Singleton @Startup... EJB).
> > >
> > > What is the preferred approach you would use?
> > >
> > > Regards
> > > LF
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/Long-running-background-tasks-using-Java-EE-6-tp4674474p4674476.html
> To start a new topic under TomEE Users, email
> ml-node+s979440n979441h29@n4.nabble.com
> To unsubscribe from TomEE Users, click here
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=979441&code=Y2NoYWNpbkBnbWFpbC5jb218OTc5NDQxfDE2NzcwMDYzOTY=>
> .
> NAML
> <http://tomee-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>
>
-----
Carlos Chacin
http://github.com/cchacin
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/Long-running-background-tasks-using-Java-EE-6-tp4674474p4674477.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
👍
On May 29, 2015 3:48 PM, "Romain Manni-Bucau" <rm...@gmail.com> wrote:
> yep, a CountDownLatch is perfect for it
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-05-29 15:45 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > @Romain
> >
> > Got it... so do i need in @PreDestroy method to wait for the async method
> > to pick up the boolean variable change and exit before exiting
> @PreDestroy
> > method or will application shutdown wait a certain amount of time for
> async
> > method executions to finish?
> > On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rm...@gmail.com>
> > wrote:
> >
> > > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > >
> > > > @Romain
> > > >
> > > > Thanks for the answer....
> > > >
> > > > I use a boolean now... the problem (if any) is that using a boolean
> > flag
> > > is
> > > > that the shutdown will take atleast the time the wait interval is....
> > > >
> > > > Did you then mean I need to in the @PreDestroy wait for the async
> > thread
> > > to
> > > > finish and exit?
> > > >
> > > >
> > > dont handle thread but your task (think business not technical)
> > >
> > >
> > > > About the thread and threadpool... since this is a long running task
> I
> > > > should have the same thread all the time right? But I agree
> > interrupting
> > > > isnt the best way....
> > > >
> > > >
> > > yep but what happen once you release it? the thread goes back in the
> > pool,
> > > it is not expected to be interrupted
> > >
> > >
> > > >
> > > > Regards
> > > > LF
> > > >
> > > >
> > > > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > > >
> > > > > > @Romain
> > > > > >
> > > > > > If the long running task (started as an @Asynchronous EJB method)
> > is
> > > > > > periodacally sleeping for say 1 minute and then perform some
> tasks
> > > and
> > > > > goes
> > > > > > to sleep again....
> > > > > >
> > > > > > Would it then be okay to on the EJB class level have a: private
> > > > volatile
> > > > > > Therad asynchronousThread; variable...
> > > > > >
> > > > > > The @Asynchronous EJB method could then before it enters its loop
> > > then
> > > > > do:
> > > > > >
> > > > > > asynchronousThread = Thread.currentThread();
> > > > > >
> > > > > > and the EJB itself in its @PreDestroy method could then do:
> > > > > >
> > > > > > asynchronousThread.interrupt();
> > > > > >
> > > > > > to make sure we can perform a shutdown in less time than the
> > actually
> > > > > sleep
> > > > > > time??
> > > > > >
> > > > > >
> > > > > the best is to have a boolean to say "stop computing" and flag it
> in
> > > > > predestroy and wait a latch where countDown is called at the end
> of
> > > the
> > > > > run. You dont have by default one thread by task but a thread of a
> > pool
> > > > so
> > > > > your proposal can have side effect +interrupt is not the best way
> to
> > > end
> > > > a
> > > > > thread.
> > > > >
> > > > >
> > > > > > Can spurious wakeups still happen or is that a thing from the
> past?
> > > > That
> > > > > is
> > > > > > do I when interrupted need to check a volatile boolean flag also
> to
> > > > make
> > > > > > sure I was interrupted for the correct reason?
> > > > > >
> > > > > > Hope for your input on the above....
> > > > > >
> > > > > > Regards
> > > > > > LF
> > > > > >
> > > > > >
> > > > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > last time I did it it was with a @Singleton @Startup starting
> an
> > > > async
> > > > > > task
> > > > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > > > >
> > > > > > > Little trick: to start an async method from "this" inject
> > > > > SessionContext
> > > > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> Tomitriber
> > > > > > > <http://www.tomitribe.com>
> > > > > > >
> > > > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> > > itsmeden@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Understand that... Unfortunately we are running Java EE6 in
> > > > > production
> > > > > > > and
> > > > > > > > cannot pull it in as a third party prod for various reasons
> > > > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > I am very happy with jbatch aka batchee.
> > > > > > > > >
> > > > > > > > > Skickat från min iPhone
> > > > > > > > >
> > > > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > > > itsmeden@gmail.com
> > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > I need to run a background task that will poll messages
> > from
> > > a
> > > > > > > > > > BlockingQueue, aggregate data (to some degree) and at
> > regular
> > > > > > > intervals
> > > > > > > > > > write the data to a file (append to a file).
> > > > > > > > > >
> > > > > > > > > > Each appserver instance will write to its own file so
> there
> > > is
> > > > no
> > > > > > > need
> > > > > > > > to
> > > > > > > > > > sync within a cluster or similar...
> > > > > > > > > >
> > > > > > > > > > I guess I could at startup create my own thread and peek
> > the
> > > > > queue
> > > > > > > > etc...
> > > > > > > > > > but if I would keep it more strict Java EE 6 and also
> need
> > > > access
> > > > > > to
> > > > > > > > > > @ApplicationScoped beans then I guess I could either use
> a
> > > > > one-off
> > > > > > > > > > programmatic EJB timer or calling an @Asynchronous EJB
> > methos
> > > > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > > > >
> > > > > > > > > > What is the preferred approach you would use?
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > > LF
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Med vänlig hälsning / Best regards
> > > > > >
> > > > > > Lars-Fredrik Smedberg
> > > > > >
> > > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > > The information contained in this electronic message and any
> > > > > > attachments to this message are intended for the exclusive use of
> > the
> > > > > > address(es) and may contain confidential or privileged
> information.
> > > If
> > > > > > you are not the intended recipient, please notify Lars-Fredrik
> > > Smedberg
> > > > > > immediately at itsmeden@gmail.com, and destroy all copies of
> this
> > > > > > message and any attachments.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Med vänlig hälsning / Best regards
> > > >
> > > > Lars-Fredrik Smedberg
> > > >
> > > > STATEMENT OF CONFIDENTIALITY:
> > > > The information contained in this electronic message and any
> > > > attachments to this message are intended for the exclusive use of the
> > > > address(es) and may contain confidential or privileged information.
> If
> > > > you are not the intended recipient, please notify Lars-Fredrik
> Smedberg
> > > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > > message and any attachments.
> > > >
> > >
> >
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
Thanks
I actually ended up with 2 CountDownLatche's... one that the actual async
work does await on with a timeout that is equal to the workinterval of the
long running job (and checking the boolean return to know if it actually
should exit or if the work interval occured) and one that is used by the
@PreDestroy so that it waits until the async job signals that its done
That way the work interval of the long running job can be long but the job
will be able to shutdown quickly when predestroy is called...
Regards
LF
On Fri, May 29, 2015 at 8:35 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> it depends also on your config but if you have another task finishing after
> (singleton) which starts an asynch task as well here you can force your
> pool to recreate thread. Then add a custom pool config and you are lost
> about what will happen ;)
>
> the point point is to handle the level you use (you can create your own
> thread is you want to interrupt it, wouldnt be portable but work in tomee),
> also makes the code more reliable. Finally about portability depending the
> impl you will be able to not to interrupt this thread
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-05-29 11:14 GMT-07:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > @Romain
> >
> > Just tried it out in a testcase... boolean for stopping and
> countdownlatch
> > for waiting in the predestroy method until the async method has ended is
> > working good...
> >
> > Thanks for the hints...
> >
> > However I still little curious when you wrote:
> >
> > "You dont have by default one thread by task but a thread of a pool so
> > your proposal can have side effect +interrupt is not the best way to end
> a
> > thread."
> >
> > Could you elaborate little on the side effects?
> >
> > Regards
> > LF
> >
> > On Fri, May 29, 2015 at 3:47 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > yep, a CountDownLatch is perfect for it
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com>
> > >
> > > 2015-05-29 15:45 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > >
> > > > @Romain
> > > >
> > > > Got it... so do i need in @PreDestroy method to wait for the async
> > method
> > > > to pick up the boolean variable change and exit before exiting
> > > @PreDestroy
> > > > method or will application shutdown wait a certain amount of time for
> > > async
> > > > method executions to finish?
> > > > On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com
> >
> > > > wrote:
> > > >
> > > > > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > > >
> > > > > > @Romain
> > > > > >
> > > > > > Thanks for the answer....
> > > > > >
> > > > > > I use a boolean now... the problem (if any) is that using a
> boolean
> > > > flag
> > > > > is
> > > > > > that the shutdown will take atleast the time the wait interval
> > is....
> > > > > >
> > > > > > Did you then mean I need to in the @PreDestroy wait for the async
> > > > thread
> > > > > to
> > > > > > finish and exit?
> > > > > >
> > > > > >
> > > > > dont handle thread but your task (think business not technical)
> > > > >
> > > > >
> > > > > > About the thread and threadpool... since this is a long running
> > task
> > > I
> > > > > > should have the same thread all the time right? But I agree
> > > > interrupting
> > > > > > isnt the best way....
> > > > > >
> > > > > >
> > > > > yep but what happen once you release it? the thread goes back in
> the
> > > > pool,
> > > > > it is not expected to be interrupted
> > > > >
> > > > >
> > > > > >
> > > > > > Regards
> > > > > > LF
> > > > > >
> > > > > >
> > > > > > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <
> > > itsmeden@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > @Romain
> > > > > > > >
> > > > > > > > If the long running task (started as an @Asynchronous EJB
> > method)
> > > > is
> > > > > > > > periodacally sleeping for say 1 minute and then perform some
> > > tasks
> > > > > and
> > > > > > > goes
> > > > > > > > to sleep again....
> > > > > > > >
> > > > > > > > Would it then be okay to on the EJB class level have a:
> private
> > > > > > volatile
> > > > > > > > Therad asynchronousThread; variable...
> > > > > > > >
> > > > > > > > The @Asynchronous EJB method could then before it enters its
> > loop
> > > > > then
> > > > > > > do:
> > > > > > > >
> > > > > > > > asynchronousThread = Thread.currentThread();
> > > > > > > >
> > > > > > > > and the EJB itself in its @PreDestroy method could then do:
> > > > > > > >
> > > > > > > > asynchronousThread.interrupt();
> > > > > > > >
> > > > > > > > to make sure we can perform a shutdown in less time than the
> > > > actually
> > > > > > > sleep
> > > > > > > > time??
> > > > > > > >
> > > > > > > >
> > > > > > > the best is to have a boolean to say "stop computing" and flag
> it
> > > in
> > > > > > > predestroy and wait a latch where countDown is called at the
> end
> > > of
> > > > > the
> > > > > > > run. You dont have by default one thread by task but a thread
> of
> > a
> > > > pool
> > > > > > so
> > > > > > > your proposal can have side effect +interrupt is not the best
> way
> > > to
> > > > > end
> > > > > > a
> > > > > > > thread.
> > > > > > >
> > > > > > >
> > > > > > > > Can spurious wakeups still happen or is that a thing from the
> > > past?
> > > > > > That
> > > > > > > is
> > > > > > > > do I when interrupted need to check a volatile boolean flag
> > also
> > > to
> > > > > > make
> > > > > > > > sure I was interrupted for the correct reason?
> > > > > > > >
> > > > > > > > Hope for your input on the above....
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > LF
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > > > > > rmannibucau@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > last time I did it it was with a @Singleton @Startup
> starting
> > > an
> > > > > > async
> > > > > > > > task
> > > > > > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > > > > > >
> > > > > > > > > Little trick: to start an async method from "this" inject
> > > > > > > SessionContext
> > > > > > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Romain Manni-Bucau
> > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> > > Tomitriber
> > > > > > > > > <http://www.tomitribe.com>
> > > > > > > > >
> > > > > > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> > > > > itsmeden@gmail.com
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > Understand that... Unfortunately we are running Java EE6
> in
> > > > > > > production
> > > > > > > > > and
> > > > > > > > > > cannot pull it in as a third party prod for various
> reasons
> > > > > > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > I am very happy with jbatch aka batchee.
> > > > > > > > > > >
> > > > > > > > > > > Skickat från min iPhone
> > > > > > > > > > >
> > > > > > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > > > > > itsmeden@gmail.com
> > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi
> > > > > > > > > > > >
> > > > > > > > > > > > I need to run a background task that will poll
> messages
> > > > from
> > > > > a
> > > > > > > > > > > > BlockingQueue, aggregate data (to some degree) and at
> > > > regular
> > > > > > > > > intervals
> > > > > > > > > > > > write the data to a file (append to a file).
> > > > > > > > > > > >
> > > > > > > > > > > > Each appserver instance will write to its own file so
> > > there
> > > > > is
> > > > > > no
> > > > > > > > > need
> > > > > > > > > > to
> > > > > > > > > > > > sync within a cluster or similar...
> > > > > > > > > > > >
> > > > > > > > > > > > I guess I could at startup create my own thread and
> > peek
> > > > the
> > > > > > > queue
> > > > > > > > > > etc...
> > > > > > > > > > > > but if I would keep it more strict Java EE 6 and also
> > > need
> > > > > > access
> > > > > > > > to
> > > > > > > > > > > > @ApplicationScoped beans then I guess I could either
> > use
> > > a
> > > > > > > one-off
> > > > > > > > > > > > programmatic EJB timer or calling an @Asynchronous
> EJB
> > > > methos
> > > > > > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > > > > > >
> > > > > > > > > > > > What is the preferred approach you would use?
> > > > > > > > > > > >
> > > > > > > > > > > > Regards
> > > > > > > > > > > > LF
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Med vänlig hälsning / Best regards
> > > > > > > >
> > > > > > > > Lars-Fredrik Smedberg
> > > > > > > >
> > > > > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > > > > The information contained in this electronic message and any
> > > > > > > > attachments to this message are intended for the exclusive
> use
> > of
> > > > the
> > > > > > > > address(es) and may contain confidential or privileged
> > > information.
> > > > > If
> > > > > > > > you are not the intended recipient, please notify
> Lars-Fredrik
> > > > > Smedberg
> > > > > > > > immediately at itsmeden@gmail.com, and destroy all copies of
> > > this
> > > > > > > > message and any attachments.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Med vänlig hälsning / Best regards
> > > > > >
> > > > > > Lars-Fredrik Smedberg
> > > > > >
> > > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > > The information contained in this electronic message and any
> > > > > > attachments to this message are intended for the exclusive use of
> > the
> > > > > > address(es) and may contain confidential or privileged
> information.
> > > If
> > > > > > you are not the intended recipient, please notify Lars-Fredrik
> > > Smedberg
> > > > > > immediately at itsmeden@gmail.com, and destroy all copies of
> this
> > > > > > message and any attachments.
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
> >
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
it depends also on your config but if you have another task finishing after
(singleton) which starts an asynch task as well here you can force your
pool to recreate thread. Then add a custom pool config and you are lost
about what will happen ;)
the point point is to handle the level you use (you can create your own
thread is you want to interrupt it, wouldnt be portable but work in tomee),
also makes the code more reliable. Finally about portability depending the
impl you will be able to not to interrupt this thread
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2015-05-29 11:14 GMT-07:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> @Romain
>
> Just tried it out in a testcase... boolean for stopping and countdownlatch
> for waiting in the predestroy method until the async method has ended is
> working good...
>
> Thanks for the hints...
>
> However I still little curious when you wrote:
>
> "You dont have by default one thread by task but a thread of a pool so
> your proposal can have side effect +interrupt is not the best way to end a
> thread."
>
> Could you elaborate little on the side effects?
>
> Regards
> LF
>
> On Fri, May 29, 2015 at 3:47 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > yep, a CountDownLatch is perfect for it
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-05-29 15:45 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> >
> > > @Romain
> > >
> > > Got it... so do i need in @PreDestroy method to wait for the async
> method
> > > to pick up the boolean variable change and exit before exiting
> > @PreDestroy
> > > method or will application shutdown wait a certain amount of time for
> > async
> > > method executions to finish?
> > > On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rm...@gmail.com>
> > > wrote:
> > >
> > > > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> > > >
> > > > > @Romain
> > > > >
> > > > > Thanks for the answer....
> > > > >
> > > > > I use a boolean now... the problem (if any) is that using a boolean
> > > flag
> > > > is
> > > > > that the shutdown will take atleast the time the wait interval
> is....
> > > > >
> > > > > Did you then mean I need to in the @PreDestroy wait for the async
> > > thread
> > > > to
> > > > > finish and exit?
> > > > >
> > > > >
> > > > dont handle thread but your task (think business not technical)
> > > >
> > > >
> > > > > About the thread and threadpool... since this is a long running
> task
> > I
> > > > > should have the same thread all the time right? But I agree
> > > interrupting
> > > > > isnt the best way....
> > > > >
> > > > >
> > > > yep but what happen once you release it? the thread goes back in the
> > > pool,
> > > > it is not expected to be interrupted
> > > >
> > > >
> > > > >
> > > > > Regards
> > > > > LF
> > > > >
> > > > >
> > > > > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <
> > itsmeden@gmail.com
> > > >:
> > > > > >
> > > > > > > @Romain
> > > > > > >
> > > > > > > If the long running task (started as an @Asynchronous EJB
> method)
> > > is
> > > > > > > periodacally sleeping for say 1 minute and then perform some
> > tasks
> > > > and
> > > > > > goes
> > > > > > > to sleep again....
> > > > > > >
> > > > > > > Would it then be okay to on the EJB class level have a: private
> > > > > volatile
> > > > > > > Therad asynchronousThread; variable...
> > > > > > >
> > > > > > > The @Asynchronous EJB method could then before it enters its
> loop
> > > > then
> > > > > > do:
> > > > > > >
> > > > > > > asynchronousThread = Thread.currentThread();
> > > > > > >
> > > > > > > and the EJB itself in its @PreDestroy method could then do:
> > > > > > >
> > > > > > > asynchronousThread.interrupt();
> > > > > > >
> > > > > > > to make sure we can perform a shutdown in less time than the
> > > actually
> > > > > > sleep
> > > > > > > time??
> > > > > > >
> > > > > > >
> > > > > > the best is to have a boolean to say "stop computing" and flag it
> > in
> > > > > > predestroy and wait a latch where countDown is called at the end
> > of
> > > > the
> > > > > > run. You dont have by default one thread by task but a thread of
> a
> > > pool
> > > > > so
> > > > > > your proposal can have side effect +interrupt is not the best way
> > to
> > > > end
> > > > > a
> > > > > > thread.
> > > > > >
> > > > > >
> > > > > > > Can spurious wakeups still happen or is that a thing from the
> > past?
> > > > > That
> > > > > > is
> > > > > > > do I when interrupted need to check a volatile boolean flag
> also
> > to
> > > > > make
> > > > > > > sure I was interrupted for the correct reason?
> > > > > > >
> > > > > > > Hope for your input on the above....
> > > > > > >
> > > > > > > Regards
> > > > > > > LF
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > > > > rmannibucau@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > last time I did it it was with a @Singleton @Startup starting
> > an
> > > > > async
> > > > > > > task
> > > > > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > > > > >
> > > > > > > > Little trick: to start an async method from "this" inject
> > > > > > SessionContext
> > > > > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> > Tomitriber
> > > > > > > > <http://www.tomitribe.com>
> > > > > > > >
> > > > > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> > > > itsmeden@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Understand that... Unfortunately we are running Java EE6 in
> > > > > > production
> > > > > > > > and
> > > > > > > > > cannot pull it in as a third party prod for various reasons
> > > > > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > I am very happy with jbatch aka batchee.
> > > > > > > > > >
> > > > > > > > > > Skickat från min iPhone
> > > > > > > > > >
> > > > > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > > > > itsmeden@gmail.com
> > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > Hi
> > > > > > > > > > >
> > > > > > > > > > > I need to run a background task that will poll messages
> > > from
> > > > a
> > > > > > > > > > > BlockingQueue, aggregate data (to some degree) and at
> > > regular
> > > > > > > > intervals
> > > > > > > > > > > write the data to a file (append to a file).
> > > > > > > > > > >
> > > > > > > > > > > Each appserver instance will write to its own file so
> > there
> > > > is
> > > > > no
> > > > > > > > need
> > > > > > > > > to
> > > > > > > > > > > sync within a cluster or similar...
> > > > > > > > > > >
> > > > > > > > > > > I guess I could at startup create my own thread and
> peek
> > > the
> > > > > > queue
> > > > > > > > > etc...
> > > > > > > > > > > but if I would keep it more strict Java EE 6 and also
> > need
> > > > > access
> > > > > > > to
> > > > > > > > > > > @ApplicationScoped beans then I guess I could either
> use
> > a
> > > > > > one-off
> > > > > > > > > > > programmatic EJB timer or calling an @Asynchronous EJB
> > > methos
> > > > > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > > > > >
> > > > > > > > > > > What is the preferred approach you would use?
> > > > > > > > > > >
> > > > > > > > > > > Regards
> > > > > > > > > > > LF
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Med vänlig hälsning / Best regards
> > > > > > >
> > > > > > > Lars-Fredrik Smedberg
> > > > > > >
> > > > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > > > The information contained in this electronic message and any
> > > > > > > attachments to this message are intended for the exclusive use
> of
> > > the
> > > > > > > address(es) and may contain confidential or privileged
> > information.
> > > > If
> > > > > > > you are not the intended recipient, please notify Lars-Fredrik
> > > > Smedberg
> > > > > > > immediately at itsmeden@gmail.com, and destroy all copies of
> > this
> > > > > > > message and any attachments.
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Med vänlig hälsning / Best regards
> > > > >
> > > > > Lars-Fredrik Smedberg
> > > > >
> > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > The information contained in this electronic message and any
> > > > > attachments to this message are intended for the exclusive use of
> the
> > > > > address(es) and may contain confidential or privileged information.
> > If
> > > > > you are not the intended recipient, please notify Lars-Fredrik
> > Smedberg
> > > > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > > > message and any attachments.
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
Just tried it out in a testcase... boolean for stopping and countdownlatch
for waiting in the predestroy method until the async method has ended is
working good...
Thanks for the hints...
However I still little curious when you wrote:
"You dont have by default one thread by task but a thread of a pool so
your proposal can have side effect +interrupt is not the best way to end a
thread."
Could you elaborate little on the side effects?
Regards
LF
On Fri, May 29, 2015 at 3:47 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> yep, a CountDownLatch is perfect for it
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-05-29 15:45 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > @Romain
> >
> > Got it... so do i need in @PreDestroy method to wait for the async method
> > to pick up the boolean variable change and exit before exiting
> @PreDestroy
> > method or will application shutdown wait a certain amount of time for
> async
> > method executions to finish?
> > On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rm...@gmail.com>
> > wrote:
> >
> > > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > >
> > > > @Romain
> > > >
> > > > Thanks for the answer....
> > > >
> > > > I use a boolean now... the problem (if any) is that using a boolean
> > flag
> > > is
> > > > that the shutdown will take atleast the time the wait interval is....
> > > >
> > > > Did you then mean I need to in the @PreDestroy wait for the async
> > thread
> > > to
> > > > finish and exit?
> > > >
> > > >
> > > dont handle thread but your task (think business not technical)
> > >
> > >
> > > > About the thread and threadpool... since this is a long running task
> I
> > > > should have the same thread all the time right? But I agree
> > interrupting
> > > > isnt the best way....
> > > >
> > > >
> > > yep but what happen once you release it? the thread goes back in the
> > pool,
> > > it is not expected to be interrupted
> > >
> > >
> > > >
> > > > Regards
> > > > LF
> > > >
> > > >
> > > > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > > >
> > > > > > @Romain
> > > > > >
> > > > > > If the long running task (started as an @Asynchronous EJB method)
> > is
> > > > > > periodacally sleeping for say 1 minute and then perform some
> tasks
> > > and
> > > > > goes
> > > > > > to sleep again....
> > > > > >
> > > > > > Would it then be okay to on the EJB class level have a: private
> > > > volatile
> > > > > > Therad asynchronousThread; variable...
> > > > > >
> > > > > > The @Asynchronous EJB method could then before it enters its loop
> > > then
> > > > > do:
> > > > > >
> > > > > > asynchronousThread = Thread.currentThread();
> > > > > >
> > > > > > and the EJB itself in its @PreDestroy method could then do:
> > > > > >
> > > > > > asynchronousThread.interrupt();
> > > > > >
> > > > > > to make sure we can perform a shutdown in less time than the
> > actually
> > > > > sleep
> > > > > > time??
> > > > > >
> > > > > >
> > > > > the best is to have a boolean to say "stop computing" and flag it
> in
> > > > > predestroy and wait a latch where countDown is called at the end
> of
> > > the
> > > > > run. You dont have by default one thread by task but a thread of a
> > pool
> > > > so
> > > > > your proposal can have side effect +interrupt is not the best way
> to
> > > end
> > > > a
> > > > > thread.
> > > > >
> > > > >
> > > > > > Can spurious wakeups still happen or is that a thing from the
> past?
> > > > That
> > > > > is
> > > > > > do I when interrupted need to check a volatile boolean flag also
> to
> > > > make
> > > > > > sure I was interrupted for the correct reason?
> > > > > >
> > > > > > Hope for your input on the above....
> > > > > >
> > > > > > Regards
> > > > > > LF
> > > > > >
> > > > > >
> > > > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > last time I did it it was with a @Singleton @Startup starting
> an
> > > > async
> > > > > > task
> > > > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > > > >
> > > > > > > Little trick: to start an async method from "this" inject
> > > > > SessionContext
> > > > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> Tomitriber
> > > > > > > <http://www.tomitribe.com>
> > > > > > >
> > > > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> > > itsmeden@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Understand that... Unfortunately we are running Java EE6 in
> > > > > production
> > > > > > > and
> > > > > > > > cannot pull it in as a third party prod for various reasons
> > > > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > I am very happy with jbatch aka batchee.
> > > > > > > > >
> > > > > > > > > Skickat från min iPhone
> > > > > > > > >
> > > > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > > > itsmeden@gmail.com
> > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > I need to run a background task that will poll messages
> > from
> > > a
> > > > > > > > > > BlockingQueue, aggregate data (to some degree) and at
> > regular
> > > > > > > intervals
> > > > > > > > > > write the data to a file (append to a file).
> > > > > > > > > >
> > > > > > > > > > Each appserver instance will write to its own file so
> there
> > > is
> > > > no
> > > > > > > need
> > > > > > > > to
> > > > > > > > > > sync within a cluster or similar...
> > > > > > > > > >
> > > > > > > > > > I guess I could at startup create my own thread and peek
> > the
> > > > > queue
> > > > > > > > etc...
> > > > > > > > > > but if I would keep it more strict Java EE 6 and also
> need
> > > > access
> > > > > > to
> > > > > > > > > > @ApplicationScoped beans then I guess I could either use
> a
> > > > > one-off
> > > > > > > > > > programmatic EJB timer or calling an @Asynchronous EJB
> > methos
> > > > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > > > >
> > > > > > > > > > What is the preferred approach you would use?
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > > LF
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Med vänlig hälsning / Best regards
> > > > > >
> > > > > > Lars-Fredrik Smedberg
> > > > > >
> > > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > > The information contained in this electronic message and any
> > > > > > attachments to this message are intended for the exclusive use of
> > the
> > > > > > address(es) and may contain confidential or privileged
> information.
> > > If
> > > > > > you are not the intended recipient, please notify Lars-Fredrik
> > > Smedberg
> > > > > > immediately at itsmeden@gmail.com, and destroy all copies of
> this
> > > > > > message and any attachments.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Med vänlig hälsning / Best regards
> > > >
> > > > Lars-Fredrik Smedberg
> > > >
> > > > STATEMENT OF CONFIDENTIALITY:
> > > > The information contained in this electronic message and any
> > > > attachments to this message are intended for the exclusive use of the
> > > > address(es) and may contain confidential or privileged information.
> If
> > > > you are not the intended recipient, please notify Lars-Fredrik
> Smedberg
> > > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > > message and any attachments.
> > > >
> > >
> >
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep, a CountDownLatch is perfect for it
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2015-05-29 15:45 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> @Romain
>
> Got it... so do i need in @PreDestroy method to wait for the async method
> to pick up the boolean variable change and exit before exiting @PreDestroy
> method or will application shutdown wait a certain amount of time for async
> method executions to finish?
> On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rm...@gmail.com>
> wrote:
>
> > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> >
> > > @Romain
> > >
> > > Thanks for the answer....
> > >
> > > I use a boolean now... the problem (if any) is that using a boolean
> flag
> > is
> > > that the shutdown will take atleast the time the wait interval is....
> > >
> > > Did you then mean I need to in the @PreDestroy wait for the async
> thread
> > to
> > > finish and exit?
> > >
> > >
> > dont handle thread but your task (think business not technical)
> >
> >
> > > About the thread and threadpool... since this is a long running task I
> > > should have the same thread all the time right? But I agree
> interrupting
> > > isnt the best way....
> > >
> > >
> > yep but what happen once you release it? the thread goes back in the
> pool,
> > it is not expected to be interrupted
> >
> >
> > >
> > > Regards
> > > LF
> > >
> > >
> > > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> > > >
> > > > > @Romain
> > > > >
> > > > > If the long running task (started as an @Asynchronous EJB method)
> is
> > > > > periodacally sleeping for say 1 minute and then perform some tasks
> > and
> > > > goes
> > > > > to sleep again....
> > > > >
> > > > > Would it then be okay to on the EJB class level have a: private
> > > volatile
> > > > > Therad asynchronousThread; variable...
> > > > >
> > > > > The @Asynchronous EJB method could then before it enters its loop
> > then
> > > > do:
> > > > >
> > > > > asynchronousThread = Thread.currentThread();
> > > > >
> > > > > and the EJB itself in its @PreDestroy method could then do:
> > > > >
> > > > > asynchronousThread.interrupt();
> > > > >
> > > > > to make sure we can perform a shutdown in less time than the
> actually
> > > > sleep
> > > > > time??
> > > > >
> > > > >
> > > > the best is to have a boolean to say "stop computing" and flag it in
> > > > predestroy and wait a latch where countDown is called at the end of
> > the
> > > > run. You dont have by default one thread by task but a thread of a
> pool
> > > so
> > > > your proposal can have side effect +interrupt is not the best way to
> > end
> > > a
> > > > thread.
> > > >
> > > >
> > > > > Can spurious wakeups still happen or is that a thing from the past?
> > > That
> > > > is
> > > > > do I when interrupted need to check a volatile boolean flag also to
> > > make
> > > > > sure I was interrupted for the correct reason?
> > > > >
> > > > > Hope for your input on the above....
> > > > >
> > > > > Regards
> > > > > LF
> > > > >
> > > > >
> > > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > last time I did it it was with a @Singleton @Startup starting an
> > > async
> > > > > task
> > > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > > >
> > > > > > Little trick: to start an async method from "this" inject
> > > > SessionContext
> > > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > > <http://www.tomitribe.com>
> > > > > >
> > > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> > itsmeden@gmail.com
> > > >:
> > > > > >
> > > > > > > Understand that... Unfortunately we are running Java EE6 in
> > > > production
> > > > > > and
> > > > > > > cannot pull it in as a third party prod for various reasons
> > > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > > >
> > > > > > > > I am very happy with jbatch aka batchee.
> > > > > > > >
> > > > > > > > Skickat från min iPhone
> > > > > > > >
> > > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > > itsmeden@gmail.com
> > > > > > > >:
> > > > > > > > >
> > > > > > > > > Hi
> > > > > > > > >
> > > > > > > > > I need to run a background task that will poll messages
> from
> > a
> > > > > > > > > BlockingQueue, aggregate data (to some degree) and at
> regular
> > > > > > intervals
> > > > > > > > > write the data to a file (append to a file).
> > > > > > > > >
> > > > > > > > > Each appserver instance will write to its own file so there
> > is
> > > no
> > > > > > need
> > > > > > > to
> > > > > > > > > sync within a cluster or similar...
> > > > > > > > >
> > > > > > > > > I guess I could at startup create my own thread and peek
> the
> > > > queue
> > > > > > > etc...
> > > > > > > > > but if I would keep it more strict Java EE 6 and also need
> > > access
> > > > > to
> > > > > > > > > @ApplicationScoped beans then I guess I could either use a
> > > > one-off
> > > > > > > > > programmatic EJB timer or calling an @Asynchronous EJB
> methos
> > > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > > >
> > > > > > > > > What is the preferred approach you would use?
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > LF
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Med vänlig hälsning / Best regards
> > > > >
> > > > > Lars-Fredrik Smedberg
> > > > >
> > > > > STATEMENT OF CONFIDENTIALITY:
> > > > > The information contained in this electronic message and any
> > > > > attachments to this message are intended for the exclusive use of
> the
> > > > > address(es) and may contain confidential or privileged information.
> > If
> > > > > you are not the intended recipient, please notify Lars-Fredrik
> > Smedberg
> > > > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > > > message and any attachments.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Med vänlig hälsning / Best regards
> > >
> > > Lars-Fredrik Smedberg
> > >
> > > STATEMENT OF CONFIDENTIALITY:
> > > The information contained in this electronic message and any
> > > attachments to this message are intended for the exclusive use of the
> > > address(es) and may contain confidential or privileged information. If
> > > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > message and any attachments.
> > >
> >
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
Got it... so do i need in @PreDestroy method to wait for the async method
to pick up the boolean variable change and exit before exiting @PreDestroy
method or will application shutdown wait a certain amount of time for async
method executions to finish?
On May 29, 2015 3:40 PM, "Romain Manni-Bucau" <rm...@gmail.com> wrote:
> 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > @Romain
> >
> > Thanks for the answer....
> >
> > I use a boolean now... the problem (if any) is that using a boolean flag
> is
> > that the shutdown will take atleast the time the wait interval is....
> >
> > Did you then mean I need to in the @PreDestroy wait for the async thread
> to
> > finish and exit?
> >
> >
> dont handle thread but your task (think business not technical)
>
>
> > About the thread and threadpool... since this is a long running task I
> > should have the same thread all the time right? But I agree interrupting
> > isnt the best way....
> >
> >
> yep but what happen once you release it? the thread goes back in the pool,
> it is not expected to be interrupted
>
>
> >
> > Regards
> > LF
> >
> >
> > On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > >
> > > > @Romain
> > > >
> > > > If the long running task (started as an @Asynchronous EJB method) is
> > > > periodacally sleeping for say 1 minute and then perform some tasks
> and
> > > goes
> > > > to sleep again....
> > > >
> > > > Would it then be okay to on the EJB class level have a: private
> > volatile
> > > > Therad asynchronousThread; variable...
> > > >
> > > > The @Asynchronous EJB method could then before it enters its loop
> then
> > > do:
> > > >
> > > > asynchronousThread = Thread.currentThread();
> > > >
> > > > and the EJB itself in its @PreDestroy method could then do:
> > > >
> > > > asynchronousThread.interrupt();
> > > >
> > > > to make sure we can perform a shutdown in less time than the actually
> > > sleep
> > > > time??
> > > >
> > > >
> > > the best is to have a boolean to say "stop computing" and flag it in
> > > predestroy and wait a latch where countDown is called at the end of
> the
> > > run. You dont have by default one thread by task but a thread of a pool
> > so
> > > your proposal can have side effect +interrupt is not the best way to
> end
> > a
> > > thread.
> > >
> > >
> > > > Can spurious wakeups still happen or is that a thing from the past?
> > That
> > > is
> > > > do I when interrupted need to check a volatile boolean flag also to
> > make
> > > > sure I was interrupted for the correct reason?
> > > >
> > > > Hope for your input on the above....
> > > >
> > > > Regards
> > > > LF
> > > >
> > > >
> > > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > last time I did it it was with a @Singleton @Startup starting an
> > async
> > > > task
> > > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > > >
> > > > > Little trick: to start an async method from "this" inject
> > > SessionContext
> > > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > <http://www.tomitribe.com>
> > > > >
> > > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > > >
> > > > > > Understand that... Unfortunately we are running Java EE6 in
> > > production
> > > > > and
> > > > > > cannot pull it in as a third party prod for various reasons
> > > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > > >
> > > > > > > I am very happy with jbatch aka batchee.
> > > > > > >
> > > > > > > Skickat från min iPhone
> > > > > > >
> > > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > > itsmeden@gmail.com
> > > > > > >:
> > > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > I need to run a background task that will poll messages from
> a
> > > > > > > > BlockingQueue, aggregate data (to some degree) and at regular
> > > > > intervals
> > > > > > > > write the data to a file (append to a file).
> > > > > > > >
> > > > > > > > Each appserver instance will write to its own file so there
> is
> > no
> > > > > need
> > > > > > to
> > > > > > > > sync within a cluster or similar...
> > > > > > > >
> > > > > > > > I guess I could at startup create my own thread and peek the
> > > queue
> > > > > > etc...
> > > > > > > > but if I would keep it more strict Java EE 6 and also need
> > access
> > > > to
> > > > > > > > @ApplicationScoped beans then I guess I could either use a
> > > one-off
> > > > > > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > > >
> > > > > > > > What is the preferred approach you would use?
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > LF
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Med vänlig hälsning / Best regards
> > > >
> > > > Lars-Fredrik Smedberg
> > > >
> > > > STATEMENT OF CONFIDENTIALITY:
> > > > The information contained in this electronic message and any
> > > > attachments to this message are intended for the exclusive use of the
> > > > address(es) and may contain confidential or privileged information.
> If
> > > > you are not the intended recipient, please notify Lars-Fredrik
> Smedberg
> > > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > > message and any attachments.
> > > >
> > >
> >
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
> >
>
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> @Romain
>
> Thanks for the answer....
>
> I use a boolean now... the problem (if any) is that using a boolean flag is
> that the shutdown will take atleast the time the wait interval is....
>
> Did you then mean I need to in the @PreDestroy wait for the async thread to
> finish and exit?
>
>
dont handle thread but your task (think business not technical)
> About the thread and threadpool... since this is a long running task I
> should have the same thread all the time right? But I agree interrupting
> isnt the best way....
>
>
yep but what happen once you release it? the thread goes back in the pool,
it is not expected to be interrupted
>
> Regards
> LF
>
>
> On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> >
> > > @Romain
> > >
> > > If the long running task (started as an @Asynchronous EJB method) is
> > > periodacally sleeping for say 1 minute and then perform some tasks and
> > goes
> > > to sleep again....
> > >
> > > Would it then be okay to on the EJB class level have a: private
> volatile
> > > Therad asynchronousThread; variable...
> > >
> > > The @Asynchronous EJB method could then before it enters its loop then
> > do:
> > >
> > > asynchronousThread = Thread.currentThread();
> > >
> > > and the EJB itself in its @PreDestroy method could then do:
> > >
> > > asynchronousThread.interrupt();
> > >
> > > to make sure we can perform a shutdown in less time than the actually
> > sleep
> > > time??
> > >
> > >
> > the best is to have a boolean to say "stop computing" and flag it in
> > predestroy and wait a latch where countDown is called at the end of the
> > run. You dont have by default one thread by task but a thread of a pool
> so
> > your proposal can have side effect +interrupt is not the best way to end
> a
> > thread.
> >
> >
> > > Can spurious wakeups still happen or is that a thing from the past?
> That
> > is
> > > do I when interrupted need to check a volatile boolean flag also to
> make
> > > sure I was interrupted for the correct reason?
> > >
> > > Hope for your input on the above....
> > >
> > > Regards
> > > LF
> > >
> > >
> > > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > last time I did it it was with a @Singleton @Startup starting an
> async
> > > task
> > > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > > >
> > > > Little trick: to start an async method from "this" inject
> > SessionContext
> > > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com>
> > > >
> > > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> > > >
> > > > > Understand that... Unfortunately we are running Java EE6 in
> > production
> > > > and
> > > > > cannot pull it in as a third party prod for various reasons
> > > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > > >
> > > > > > I am very happy with jbatch aka batchee.
> > > > > >
> > > > > > Skickat från min iPhone
> > > > > >
> > > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > > itsmeden@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > I need to run a background task that will poll messages from a
> > > > > > > BlockingQueue, aggregate data (to some degree) and at regular
> > > > intervals
> > > > > > > write the data to a file (append to a file).
> > > > > > >
> > > > > > > Each appserver instance will write to its own file so there is
> no
> > > > need
> > > > > to
> > > > > > > sync within a cluster or similar...
> > > > > > >
> > > > > > > I guess I could at startup create my own thread and peek the
> > queue
> > > > > etc...
> > > > > > > but if I would keep it more strict Java EE 6 and also need
> access
> > > to
> > > > > > > @ApplicationScoped beans then I guess I could either use a
> > one-off
> > > > > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > > >
> > > > > > > What is the preferred approach you would use?
> > > > > > >
> > > > > > > Regards
> > > > > > > LF
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Med vänlig hälsning / Best regards
> > >
> > > Lars-Fredrik Smedberg
> > >
> > > STATEMENT OF CONFIDENTIALITY:
> > > The information contained in this electronic message and any
> > > attachments to this message are intended for the exclusive use of the
> > > address(es) and may contain confidential or privileged information. If
> > > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > > immediately at itsmeden@gmail.com, and destroy all copies of this
> > > message and any attachments.
> > >
> >
>
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
Thanks for the answer....
I use a boolean now... the problem (if any) is that using a boolean flag is
that the shutdown will take atleast the time the wait interval is....
Did you then mean I need to in the @PreDestroy wait for the async thread to
finish and exit?
About the thread and threadpool... since this is a long running task I
should have the same thread all the time right? But I agree interrupting
isnt the best way....
Regards
LF
On Fri, May 29, 2015 at 3:14 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > @Romain
> >
> > If the long running task (started as an @Asynchronous EJB method) is
> > periodacally sleeping for say 1 minute and then perform some tasks and
> goes
> > to sleep again....
> >
> > Would it then be okay to on the EJB class level have a: private volatile
> > Therad asynchronousThread; variable...
> >
> > The @Asynchronous EJB method could then before it enters its loop then
> do:
> >
> > asynchronousThread = Thread.currentThread();
> >
> > and the EJB itself in its @PreDestroy method could then do:
> >
> > asynchronousThread.interrupt();
> >
> > to make sure we can perform a shutdown in less time than the actually
> sleep
> > time??
> >
> >
> the best is to have a boolean to say "stop computing" and flag it in
> predestroy and wait a latch where countDown is called at the end of the
> run. You dont have by default one thread by task but a thread of a pool so
> your proposal can have side effect +interrupt is not the best way to end a
> thread.
>
>
> > Can spurious wakeups still happen or is that a thing from the past? That
> is
> > do I when interrupted need to check a volatile boolean flag also to make
> > sure I was interrupted for the correct reason?
> >
> > Hope for your input on the above....
> >
> > Regards
> > LF
> >
> >
> > On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > last time I did it it was with a @Singleton @Startup starting an async
> > task
> > > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> > >
> > > Little trick: to start an async method from "this" inject
> SessionContext
> > > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com>
> > >
> > > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> > >
> > > > Understand that... Unfortunately we are running Java EE6 in
> production
> > > and
> > > > cannot pull it in as a third party prod for various reasons
> > > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > > >
> > > > > I am very happy with jbatch aka batchee.
> > > > >
> > > > > Skickat från min iPhone
> > > > >
> > > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > > itsmeden@gmail.com
> > > > >:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > I need to run a background task that will poll messages from a
> > > > > > BlockingQueue, aggregate data (to some degree) and at regular
> > > intervals
> > > > > > write the data to a file (append to a file).
> > > > > >
> > > > > > Each appserver instance will write to its own file so there is no
> > > need
> > > > to
> > > > > > sync within a cluster or similar...
> > > > > >
> > > > > > I guess I could at startup create my own thread and peek the
> queue
> > > > etc...
> > > > > > but if I would keep it more strict Java EE 6 and also need access
> > to
> > > > > > @ApplicationScoped beans then I guess I could either use a
> one-off
> > > > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > > > (started/called from a @Singleton @Startup... EJB).
> > > > > >
> > > > > > What is the preferred approach you would use?
> > > > > >
> > > > > > Regards
> > > > > > LF
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
> >
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> @Romain
>
> If the long running task (started as an @Asynchronous EJB method) is
> periodacally sleeping for say 1 minute and then perform some tasks and goes
> to sleep again....
>
> Would it then be okay to on the EJB class level have a: private volatile
> Therad asynchronousThread; variable...
>
> The @Asynchronous EJB method could then before it enters its loop then do:
>
> asynchronousThread = Thread.currentThread();
>
> and the EJB itself in its @PreDestroy method could then do:
>
> asynchronousThread.interrupt();
>
> to make sure we can perform a shutdown in less time than the actually sleep
> time??
>
>
the best is to have a boolean to say "stop computing" and flag it in
predestroy and wait a latch where countDown is called at the end of the
run. You dont have by default one thread by task but a thread of a pool so
your proposal can have side effect +interrupt is not the best way to end a
thread.
> Can spurious wakeups still happen or is that a thing from the past? That is
> do I when interrupted need to check a volatile boolean flag also to make
> sure I was interrupted for the correct reason?
>
> Hope for your input on the above....
>
> Regards
> LF
>
>
> On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > last time I did it it was with a @Singleton @Startup starting an async
> task
> > in @PostCOnstruct and waiting for shutdown in @PreDestroy.
> >
> > Little trick: to start an async method from "this" inject SessionContext
> > (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> >
> > > Understand that... Unfortunately we are running Java EE6 in production
> > and
> > > cannot pull it in as a third party prod for various reasons
> > > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> > >
> > > > I am very happy with jbatch aka batchee.
> > > >
> > > > Skickat från min iPhone
> > > >
> > > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> > itsmeden@gmail.com
> > > >:
> > > > >
> > > > > Hi
> > > > >
> > > > > I need to run a background task that will poll messages from a
> > > > > BlockingQueue, aggregate data (to some degree) and at regular
> > intervals
> > > > > write the data to a file (append to a file).
> > > > >
> > > > > Each appserver instance will write to its own file so there is no
> > need
> > > to
> > > > > sync within a cluster or similar...
> > > > >
> > > > > I guess I could at startup create my own thread and peek the queue
> > > etc...
> > > > > but if I would keep it more strict Java EE 6 and also need access
> to
> > > > > @ApplicationScoped beans then I guess I could either use a one-off
> > > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > > (started/called from a @Singleton @Startup... EJB).
> > > > >
> > > > > What is the preferred approach you would use?
> > > > >
> > > > > Regards
> > > > > LF
> > > >
> > >
> >
>
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
If the long running task (started as an @Asynchronous EJB method) is
periodacally sleeping for say 1 minute and then perform some tasks and goes
to sleep again....
Would it then be okay to on the EJB class level have a: private volatile
Therad asynchronousThread; variable...
The @Asynchronous EJB method could then before it enters its loop then do:
asynchronousThread = Thread.currentThread();
and the EJB itself in its @PreDestroy method could then do:
asynchronousThread.interrupt();
to make sure we can perform a shutdown in less time than the actually sleep
time??
Can spurious wakeups still happen or is that a thing from the past? That is
do I when interrupted need to check a volatile boolean flag also to make
sure I was interrupted for the correct reason?
Hope for your input on the above....
Regards
LF
On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> last time I did it it was with a @Singleton @Startup starting an async task
> in @PostCOnstruct and waiting for shutdown in @PreDestroy.
>
> Little trick: to start an async method from "this" inject SessionContext
> (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > Understand that... Unfortunately we are running Java EE6 in production
> and
> > cannot pull it in as a third party prod for various reasons
> > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> >
> > > I am very happy with jbatch aka batchee.
> > >
> > > Skickat från min iPhone
> > >
> > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > >
> > > > Hi
> > > >
> > > > I need to run a background task that will poll messages from a
> > > > BlockingQueue, aggregate data (to some degree) and at regular
> intervals
> > > > write the data to a file (append to a file).
> > > >
> > > > Each appserver instance will write to its own file so there is no
> need
> > to
> > > > sync within a cluster or similar...
> > > >
> > > > I guess I could at startup create my own thread and peek the queue
> > etc...
> > > > but if I would keep it more strict Java EE 6 and also need access to
> > > > @ApplicationScoped beans then I guess I could either use a one-off
> > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > (started/called from a @Singleton @Startup... EJB).
> > > >
> > > > What is the preferred approach you would use?
> > > >
> > > > Regards
> > > > LF
> > >
> >
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Romain
Thanks for sharing your thoughts and thanks for reminding (think I've seen
it in some tutorial) me of the trick, this way I not need to devide the
func in two seperate classes.
Regards
LF
On Sat, Apr 18, 2015 at 7:58 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> last time I did it it was with a @Singleton @Startup starting an async task
> in @PostCOnstruct and waiting for shutdown in @PreDestroy.
>
> Little trick: to start an async method from "this" inject SessionContext
> (sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
>
> > Understand that... Unfortunately we are running Java EE6 in production
> and
> > cannot pull it in as a third party prod for various reasons
> > On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> >
> > > I am very happy with jbatch aka batchee.
> > >
> > > Skickat från min iPhone
> > >
> > > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <
> itsmeden@gmail.com
> > >:
> > > >
> > > > Hi
> > > >
> > > > I need to run a background task that will poll messages from a
> > > > BlockingQueue, aggregate data (to some degree) and at regular
> intervals
> > > > write the data to a file (append to a file).
> > > >
> > > > Each appserver instance will write to its own file so there is no
> need
> > to
> > > > sync within a cluster or similar...
> > > >
> > > > I guess I could at startup create my own thread and peek the queue
> > etc...
> > > > but if I would keep it more strict Java EE 6 and also need access to
> > > > @ApplicationScoped beans then I guess I could either use a one-off
> > > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > > (started/called from a @Singleton @Startup... EJB).
> > > >
> > > > What is the preferred approach you would use?
> > > >
> > > > Regards
> > > > LF
> > >
> >
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Long running background tasks using Java EE 6
Posted by Romain Manni-Bucau <rm...@gmail.com>.
last time I did it it was with a @Singleton @Startup starting an async task
in @PostCOnstruct and waiting for shutdown in @PreDestroy.
Little trick: to start an async method from "this" inject SessionContext
(sc) and do sc.getBusinessLocal(MyEjb.class).myAsync();
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2015-04-18 16:59 GMT+02:00 Lars-Fredrik Smedberg <it...@gmail.com>:
> Understand that... Unfortunately we are running Java EE6 in production and
> cannot pull it in as a third party prod for various reasons
> On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
>
> > I am very happy with jbatch aka batchee.
> >
> > Skickat från min iPhone
> >
> > > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> > >
> > > Hi
> > >
> > > I need to run a background task that will poll messages from a
> > > BlockingQueue, aggregate data (to some degree) and at regular intervals
> > > write the data to a file (append to a file).
> > >
> > > Each appserver instance will write to its own file so there is no need
> to
> > > sync within a cluster or similar...
> > >
> > > I guess I could at startup create my own thread and peek the queue
> etc...
> > > but if I would keep it more strict Java EE 6 and also need access to
> > > @ApplicationScoped beans then I guess I could either use a one-off
> > > programmatic EJB timer or calling an @Asynchronous EJB methos
> > > (started/called from a @Singleton @Startup... EJB).
> > >
> > > What is the preferred approach you would use?
> > >
> > > Regards
> > > LF
> >
>
Re: Long running background tasks using Java EE 6
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
Understand that... Unfortunately we are running Java EE6 in production and
cannot pull it in as a third party prod for various reasons
On Apr 18, 2015 4:58 PM, <ka...@gmail.com> wrote:
> I am very happy with jbatch aka batchee.
>
> Skickat från min iPhone
>
> > 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <it...@gmail.com>:
> >
> > Hi
> >
> > I need to run a background task that will poll messages from a
> > BlockingQueue, aggregate data (to some degree) and at regular intervals
> > write the data to a file (append to a file).
> >
> > Each appserver instance will write to its own file so there is no need to
> > sync within a cluster or similar...
> >
> > I guess I could at startup create my own thread and peek the queue etc...
> > but if I would keep it more strict Java EE 6 and also need access to
> > @ApplicationScoped beans then I guess I could either use a one-off
> > programmatic EJB timer or calling an @Asynchronous EJB methos
> > (started/called from a @Singleton @Startup... EJB).
> >
> > What is the preferred approach you would use?
> >
> > Regards
> > LF
>
Re: Long running background tasks using Java EE 6
Posted by ka...@gmail.com.
I am very happy with jbatch aka batchee.
Skickat från min iPhone
> 18 apr 2015 kl. 16:36 skrev Lars-Fredrik Smedberg <it...@gmail.com>:
>
> Hi
>
> I need to run a background task that will poll messages from a
> BlockingQueue, aggregate data (to some degree) and at regular intervals
> write the data to a file (append to a file).
>
> Each appserver instance will write to its own file so there is no need to
> sync within a cluster or similar...
>
> I guess I could at startup create my own thread and peek the queue etc...
> but if I would keep it more strict Java EE 6 and also need access to
> @ApplicationScoped beans then I guess I could either use a one-off
> programmatic EJB timer or calling an @Asynchronous EJB methos
> (started/called from a @Singleton @Startup... EJB).
>
> What is the preferred approach you would use?
>
> Regards
> LF