@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 <rmannibu...@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 <itsme...@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" <rmannibu...@gmail.com> > > wrote: > > > > > 2015-05-29 15:35 GMT+02:00 Lars-Fredrik Smedberg <itsme...@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 < > > > rmannibu...@gmail.com > > > > > > > > > wrote: > > > > > > > > > 2015-05-29 14:55 GMT+02:00 Lars-Fredrik Smedberg < > itsme...@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 < > > > > > rmannibu...@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 < > > > itsme...@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, <karl.kil...@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 < > > > > > > > itsme...@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 itsme...@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 itsme...@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 itsme...@gmail.com, and destroy all copies of this message and any attachments.
