Multithreaded daemon? High level help needed.

For starters, I'm pretty new to Java. My background is mostly with PHP. This is really my first Java application save for hello world type stuff.

I'm in the process of writing a multi-threaded web crawler with a very specific purpose - not SE type stuff. I've got the basic functionality written including all of the threading using a thread pool executor, but what I'm not sure about is the deployment.

I need this to run as a daemon or service, so to speak. I want to be able to issue stop, start, restart commands and have it be able to intercept those interrupts and be able to shut down cleanly - each thread needs to either abandon or finish its work in a clean manner.

I was wondering what the best approach for this is?

I also would like the API to be available from many interfaces: a web GUI, a web service, and possibly a desktop GUI. Mostly for administration purposes. This includes the ability to issue stop, start, restart commands as well as having access to other methods which give me information about the status and progress.

I was told by one Java developer that using an MBean to kick off the process and exposing methods from the MBean for shut down, etc. might be one way of doing this. I also have read about EJBs a bit and they seem to be meant for exposing an API to many front ends, but I'm just not sure how they apply here.

I'm really just not sure what is the best solution for what I'm trying to do, so I figured I would garner some feedback from a larger community. Any help or suggestions are greatly appreciated.

Thanks!

- Jason

Part of this depends on what platform. Daemon sounds like UNIX. You will have to look into how shell out your application on system start.

EJB, afaik, is for database. MBean sounds like it requires a container, that is, a J2EE server, to support it.

Depending on the OS, there are generally means of inter-process communications available, such as named pipes. I'd suggest looking into what your OS supplies, and then looking into what Java support is available. What you choose will depend on the OS, Java, and the client applications that will control the daemon and their capabilities.

A quick and dirty way is to simply place files in a directory, and have your application monitor the directory. When it sees a new file, the file name tips it off as to what to do.

Quote:

---

Originally Posted by Steve11235

Part of this depends on what platform. Daemon sounds like UNIX. You will have to look into how shell out your application on system start.

EJB, afaik, is for database. MBean sounds like it requires a container, that is, a J2EE server, to support it.

Depending on the OS, there are generally means of inter-process communications available, such as named pipes. I'd suggest looking into what your OS supplies, and then looking into what Java support is available. What you choose will depend on the OS, Java, and the client applications that will control the daemon and their capabilities.

A quick and dirty way is to simply place files in a directory, and have your application monitor the directory. When it sees a new file, the file name tips it off as to what to do.

---

I'd prefer it not be so OS bound. Also, most of those solutions sound pretty kludgey.

An MBean (or even using EJB for that matter) would definitely require an app server, which is fine. If I could use Glassfish to mimic a daemon/service and control its life cycle from within the container I would be happy with that. Any ideas on that front?

For OS independence, I can suggest two options.

1. Have your application implement a ServerSocketChannel and wait for connections from control clients. This is actually fairly simple from your application's perspective. Your control clients would have to be able to connect to that socket, which isn't all that hard, either. This is a clean, efficient approach.

2. You could host your application inside something like Glassfish, which would run as a service or daemon. Clients could send send control requests to a servlet using get or post requests, or through a Web service. Since your application and the servlet are both running in the same container, your application need only implement a static method for the servlet to communicate with it. To me, using a Web application server to support a single, non-Web application is overkill, but it would work fine, and control requests could be sent using a browser as well as from an application.

Quote:

---

Originally Posted by Steve11235

For OS independence, I can suggest two options.

2. You could host your application inside something like Glassfish, which would run as a service or daemon. Clients could send send control requests to a servlet using get or post requests, or through a Web service. Since your application and the servlet are both running in the same container, your application need only implement a static method for the servlet to communicate with it. To me, using a Web application server to support a single, non-Web application is overkill, but it would work fine, and control requests could be sent using a browser as well as from an application.

---

A web service api and a web front end GUI are both in the near future, which is why using Glassfish is on my radar. I really like the idea of containing it like that.

So to recap, you're saying that any static method of any class is available to any class running inside of the same container, regardless of deployment? So an MBean's static methods would be available to a servelet, etc? If so that's perfect.

The socket idea isn't so bad, either. I might look into that anyway just to keep the crawler mobile and lightweight.

Thanks for the suggestions!