Hi, When we needed that kind of functionality in tomcat we created an implementation of the old commonj.work and commonj.timer api using timers and threads. With that implementation we could port the application to websphere when needed.
2015-02-13 17:22 GMT-02:00 Terence M. Bandoian <tere...@tmbsw.com>: > On 2/13/2015 8:52 AM, Kevin Hale Boyes wrote: > >> I'll look into the timers for sure. >> I've also noticed that my application (lots of code) also uses Executors >> and ExecutorService so I might do something there. >> >> One of the things that WorkManager gave us, and we take advantage of, is a >> callback handler that lets us know when the work was accepted for >> processing and when it was complete. I'll have to find replacements for >> that feature. Maybe that's easily done with Future's in the concurrency >> framework. >> >> Thanks for your help. >> Kevin >> >> On 13 February 2015 at 06:15, David kerber <dcker...@verizon.net> wrote: >> >> On 2/13/2015 7:29 AM, Daniel Mikusa wrote: >>> >>> On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes <kcbo...@gmail.com> >>>> wrote: >>>> >>>> I currently have an application running on weblogic that I'm moving >>>> over >>>> >>>>> to >>>>> tomcat 8. >>>>> One of the things the application does is run background jobs using the >>>>> commonj WorkManager. These jobs are managed by weblogic which seems to >>>>> be >>>>> the recommended practice. >>>>> >>>>> What is the best/recommended way to run background jobs in Tomcat 8? >>>>> >>>>> >>>>> Personally I'd use Spring, which has a nice and simple way to schedule >>>> tasks. I'd also be using Spring for other things though and I'm not >>>> sure >>>> I'd pull it in just for scheduled tasks. >>>> >>>> I use java.util.timer for my scheduled jobs in tomcat. >>> >>> >>> >>> A quick google search came up with this library. >>>> >>>> http://commonj.myfoo.de/ >>>> >>>> Haven't personally used it though. >>>> >>>> I suppose another option would be to just use java.util.concurrent. >>>> >>>> Dan >>>> >>>> >>>> >>>> Thanks, >>>>> Kevin >>>>> >>>> > > I've used something similar to the following in the past: > > > public class AServletContextListener implements ServletContextListener > { > > private ScheduledExecutorService executor; > > > /** > * Constructs AServletContextListener object. > */ > > public AServletContextListener() > { > } > > > /** > * Invoked when context is initialized. > * > * @param sce triggering ServletContextEvent > */ > > public void contextInitialized( ServletContextEvent sce ) > { > if ( executor == null ) > { > executor = Executors.newSingleThreadScheduledExecutor(); > > Calendar firstRunTime = new GregorianCalendar(); > firstRunTime.set( Calendar.HOUR_OF_DAY, 12 ); > firstRunTime.set( Calendar.MINUTE, 0 ); > firstRunTime.set( Calendar.SECOND, 0 ); > firstRunTime.set( Calendar.MILLISECOND, 0 ); > > executor.scheduleAtFixedRate( > new ARunnable(), > firstRunTime.getTimeInMillis() - > System.currentTimeMillis(), > 1000 * 60 * 60 * 24, > TimeUnit.MILLISECONDS ); > } > } > > > /** > * Invoked when context is destroyed. > * > * @param sce triggering ServletContextEvent > */ > > public void contextDestroyed( ServletContextEvent sce ) > { > if ( executor != null ) > { > boolean isTerminated = false; > > executor.shutdown(); > > do > { > try > { > isTerminated = executor.awaitTermination( > 1, TimeUnit.SECONDS ); > } > catch ( InterruptedException ignore ) > { > } > } > while ( !isTerminated ); > > executor = null; > > Thread.yield(); > } > } > > } > > > It's simple, not very much code and gets the job done. The call to > Thread.yield was added to eliminate an error message in the Tomcat logs. > > -Terence Bandoian > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
