@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 <rmannibu...@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 <itsme...@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 < > 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. > > > -- 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.
