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