views:

89

answers:

5

Hello
I have a very simple Java application which downloads a set of foreign exchanges rates from Yahoo! finance and performs some calculations on them. I am currently running this application in Eclipse.
I would now like to do two things:
1. Deploy the application on a VPS so that it can run 24 x 7
2. Develop a management console, so that I can configure the application Ex. change the foreign exchange rate pairs being monitored, change the sampling interval etc. and visualise the data.


I done some research into this and think this should achievable using technologies Spring MVC and JSPs, JSTL, JChartFree/Google Visualisation API.


What I can't quite work out is how I will make the application run 24 x 7. Looking at the way web applications work it seems that a web application will serve a request and then exit (well ok, not exit but listen for new requests). This is no good for me because of point #1 above. What methods can I use to make the application run 24 x 7 and serve up its current state on demand?
Thanks

+3  A: 

Create a Web application and put it in a Web container like Tomcat or Jetty. Use Spring to create persistent processes (in that the application context will launch a process or thread pool). Use JMX to configure the behaviour of the application, start/stop it, etc. There are sections in the Spring reference about integrating JMX.

cletus
+1  A: 

I think you are looking for a job scheduler like quartz. You can embed it into your web application and have it execute jobs without being called as a web request.

tangens
Or just `java.util.TimerTask`. But in this specific case he just want to run it 24/7. That's not up to a job scheduler then.
BalusC
He said "... change the sampling interval". This sounds like a periodically running job.
tangens
+2  A: 

Run it as a background running thread of which you've a handle in the ServletContext (actually: the application scope). The ServletContextListener is perfectly suitable for this. E.g.

public class Config implements ServletContextListener {

    private BackgroundTask backgroundTask = new BackgroundTask(); // Extends Thread.

    public void contextInitialized(ServletContextEvent event) {
        event.getServletContext().setAttribute("config", this);
        backgroundTask.start();
    }

    public BackgroundTask getBackgroundTask() { 
        return backgroundTask;
    }

}

So that you can access it in your servlets as follows:

public void doSomething(HttpServletRequest request, HttpServletResponse response) {
    Config config = (Config) getServletContext().getAttribute("config");
    BackgroundTask backgroundTask = config.getBackgroundTask();
    // Now do your thing with it. E.g. backgroundTask.getStatus() ?
}

Of course don't forget to set the BackgroundTask to be a daemon thread so that your appserver won't hang during shutdown because it's waiting for the thread to finish. You can do it before calling start() or just in its constructor.

public BackgroundTask() {
    setDaemon(true);
}
BalusC
You'd probably want to set a flag on the backgroundTask to get it to stop in the contextDestroyed method as well. Something like backgroundTask.doStop(); backgroundTask.join();
Taylor Leese
Or just do `setDaemon(true)` in its c'tor.
BalusC
+4  A: 

You're right that this is unlikely to work well as a webapp - typically they do take requests as their input, and do some processing to produce HTML output. Not always, but that's certainly the general framework that they're normally used in, and I don't think your particular case would fit the model too well.

It sounds, however, like you want to provide a webapp interface in order to query the status of your application. This does sound valid.

Really it seems like there are two separate components here:

  1. The application itself, which doesn't really have anything to do with the web and should run as a "normal" application on the box, probably being run as a background daemon/service.
  2. The status querying functionality, which listens for HTTP requests and serves up a relatively simple response based on the state of the application.

Of course, the app would need to have some way of communicating its status, which is really the crux of your question. One very simple way that may be appropriate, is if the application logs what it's doing to flat files/a database, and your status-displaying webapp reads this information and forms its response out of it.

Another approach would be to have the application provide some web service functionality; i.e. listen on its own sockets and provide responses to anything that calls it programmatically. Then your webapp could just make these calls and format the received data. See, for example, this CXF tutorial; if you don't have complicated requirements, web services can be as simple as writing a normal Java method, annotating it and dropping a new JAR in your classpath.

Finally you may be able to make JMX work - this is the same technology behind JConsole, and lets you define your own managed beans that can be queried. If you've already defined some MBeans for JConsole, this would be a natural step. See this document for examples of how to write a client that also accesses this data.

Just remember that the fundamental question is one of how to programatically access the status of a running daemon, and there are a lot of ways to do it; with the "best" one depending on many factors.

Andrzej Doyle
A: 

I assume that your application must serve live data.

  • at server side use job scheduler or other solution
  • at client side (web browser) use javascript/ajax code to refresh live data

If you are open to use JSF you can use:

cetnar