Scheduling a servlet in WebSphere Application Server
Published January 16th, 2008 in WebSphere
Lot of times we need to schedule a servlet or JSP that runs at regular intervals. . Here I am going to talk about how to schedule a servlet to run at regular intervals which is deployed in WebSphere Application Server. The easiest way to schedule a server is to call a TimerTask class from within a servlet which is loaded at the time of startup
Step 1
Create a TimerTask subclass.
The first step in writing a scheduler will be creating a class extending from java.util.TimerTask. This class would contain the necessary code that needs to be executed at regular intervals. For eg:
package com.scheduler; import java.util.TimerTask; public class MyAction extends TimerTask { public void run() { System.out.println("Run method called......."); } }
Step 2
Create a servlet that calls MyAction
The next step in creating the scheduler will be creating a servlet that will be loaded at the time of startup. We need to override the init method of this servlet so that the code will be executed during application server startup without the help of any external agent. Also we need to make an entry in the web.xml to make sure that the servlet will be loaded at application server startup. For eg:
package com.scheduler; import java.io.IOException; import java.util.Date; import java.util.Timer; import javax.servlet.Servlet; import javax.servlet.ServletConfig; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class SchedulerServlet extends HttpServlet implements Servlet { protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException { // TODO Auto-generated method stub } protected void doPost(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException { // TODO Auto-generated method stub } public void init(ServletConfig config) throws ServletException { long interval = Long.parseLong(config.getInitParameter("interval")) * 60 * 1000; MyAction action = new MyAction(); Timer timer = new Timer(); timer.schedule(action, new Date(), interval); } }
In the above code I am expecting the interval value from web.xml as a servlet init parameter. Assuming the init parameter in minutes, I converted it to milliseconds and schedule the action to run in specified intervals. My web.xml looks like below.
<servlet> <display-name>SchedulerServlet</display-name> <servlet-name>SchedulerServlet</servlet-name> <servlet-class>com.scheduler.SchedulerServlet</servlet-class> <init-param> <param-name>interval</param-name> <param-value>5</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>SchedulerServlet</servlet-name> <url-pattern>/SchedulerServlet</url-pattern> </servlet-mapping>
Here the
Now start your application server and deploy the web application. You can see a “Run method called…….” is printed on the console every 5 minutes.
Run method called....... Run method called....... Run method called.......
If you enjoyed this post, make sure you subscribe to my RSS feed!
Related Posts:
Thanks, exacly what I looking for
Thanks for the information. One question.
I typically avoid creating my own threads within the WebSphere container because I’m taking away resources
away from the container. I realize if I were to use something like the WebSphere scheduler or alarm manger
resources will be used but at least WebSphere will know about the resource use. The example you provide is
lightweight and straitforward and therefore I’m inclined to use the strategy as you have documented.
Can you comment on your experiences with using this strategy in WebSphere and creating your own threads within
the container?
As you mentioned if we create our own thread in WebSphere, none of the WebSphere resources will be available in our thread. So if our scheduler needs the context or any other container provided information we should not go for the TimerTask scheduler approach.
We should use this approach only if we need a scheduler that does not require any of the container resources. I feel this approach is more like creating a scheduler using Cron job or something. I was using this approach for polling a directory and for invoking a webservice using the polled data. In my case it worked well as I was not using any of the WebSphere resources. This approach is good if we need a very simple scheduler in WebSphere that does not require any container resources.
Unluckily there is no other option to schedule a servlet in WebSphere as far as I know. The WebSphere scheduler or alarm manager is used for scheduling an EJB or JMS. Correct me if I am wrong.
HI. IBM notes:When inside these managed environments, the Timer API (or WebSphere Scheduler API) is a much better alternative to java.util.Timer: ** java.util.Timer should never be used within managed environments, as it creates threads outside the purview of the container. **
It appears you can use the Scheduler API for what you want (servlet) - bit check the Info Center for more details under the ‘Developing and scheduling tasks’ section:
“Creating and manipulating scheduled tasks through the Scheduler interface is only supported from within the EJB container or Web container (Enterprise beans or servlets). Looking up and using a configured scheduler from a J2EE application client container is not supported.”