On Thu, 13 Oct 2005 11:40:57 +0100, HalcyonWild <>
wrote:
>
> Ross Bamford wrote:
>> Start with something along the lines of:
>>
>> <pseudocode>
>> public class LifecycleListener implements
>> javax.servlet.ServletContextListener {
>>
>> private volatile Thread manager;
>>
>> private static class Manager implements Runnable {
>> public void run {
>> Thead me = Thread.currentThread();
>> while (manager == me) {
>>
>> // Do your stuff here
>>
>> try {
>> Thread.sleep(10000)
>> } catch (InterruptedException e) {
>> // could be we're to stop, or just a 'spurious wakeup'
>> }
>> }
>> }
>> }
>>
>> public void contextInitialized(...) {
>> manager = new Thread(new Manager());
>> manager.start()
>> }
>>
>> public void contextDestroyed(...) {
>> Thread t = manager;
>> manager = null;
>> t.interrupt();
>> }
>> }
>> </pseudocode>
>>
>
> Hi ,
>
> ServletContextListener is one method. I was also thinking about this
> problem , and ServletContextListener did not occur to me.
>
> I thought, in the init() of ServletPoll, we can call another plain
> Runnable java class. I do not know if there is something wrong in doing
> this, but I am not sure. Is there anything wrong with doing this.
> The only thing I can think of is that , the server thread running might
> be blocked by ServletPoll, while ServletMain, waits to get its control,
> to process subsequent requests.
> Or might be I am wrong. There are two separate server threads for
> ServletMain and ServletPoll. Please advise. Thanks.
>
I wouldn't suggest going down that route. If I understand you correctly
you're suggesting something like the following:
<pseudocode>
public class ServletPoll extends javax.servlet.http.HttpServlet {
public void init() {
Runnable lifecycleMgr = new LifecycleManager();
lifecycleMgr.run();
}
public void doGet(HttpServletRequest req, HttpServletResponse resp) {
// what on earth goes here?
}
}
</pseudocode>
IIRC this is a very bad idea, since theres probably no guarantee that the
init() calls will be made on separate threads (you should check the
Servlet spec to be sure because I haven't), and just calling the run()
method on a runnable does NOT start a new thread. So not only would your
init() method fail to return (bad in itself) but you may well prevent
other servlets being initialized too. The server would probably not hook
it up to service requests, which is what I think you mean when you say
ServletPoll might block the server thread.
The thread model with Servlets is actually slightly more complex than you
imply, and usually involves a thread pool, with the next free thread
handling requests as they come in. I think the spec is fairly non-specific
about the specifics of the threading model, and instead chooses a very
open-ended approach (if it doubt, assume it's not safe), to allow servers
to manage the threading how they choose according to the performance and
resource requirements.
Of course, the real question is, why is ServletPoll even a Servlet? What
is it serving, i.e. what would you be doing with the doGet, doPost, or
whatever methods, in that class? A servlet should aim to process
individual requests, in any order, generating responses as appropriate, as
quickly and with as little shared state as possible (read: none). Think
the MVC controller. Another, entirely separate part is application,
request and session lifecycle and initialization, and for this the spec
provides separate interfaces to hook into these things, which in this
particular case means ServletContextListener.
If you are determined, you could probably get away with _starting a new
thread_ from the ServletPoll.init() method, allowing the method to return.
I'd guess you'd be on shaky ground, however, with regard to running on
different app servers and platforms, and you would of course need to
consider graceful shutdown of your new thread - not just for server
shutdown but also because it's possible to dynamically deploy and undeploy
apps in most containers.
--
Ross Bamford -
Similar Threads
