How to create a thread that runs all the time my application is running

Question

EDIT: I'm now sure that the problem is related to the while (true) loop holding all other commands as I've commented it out and the application deploys without the attached exception. I'm not sure how much it is important but my ServletContextListener implementation looks like this:

public class BidPushService implements ServletContextListener{

public void contextInitialized(ServletContextEvent sce) {   
//Some init code not relevant, omitted for clarity
      BidPushThread t= new BidPushThread();
      t.setServletContext(sce.getServletContext());
      t.run();
}

So now the thread is run when the app is deployed but because the while loop is commented it has no real meaning.

I need to have a thread run in the background when my application loads and constantly (without a timeout) check a certain queue for objects. Of course, once there are objects, it "takes care of them" and then continues to check the queue.

Currently, I'm implementing the ServletContextListener interface and I'm being called when the app loads. In it, I do a few maintenance things and start a thread which I inherited from java.lang.Thread.

Here is where my problem begins (or so I think). In my run() method, I have a

while (true) {
    //some code which doesn't put the thread to sleep ever
}

When I try to deploy my app to the server I get a java.util.concurrent.TimeOutException. What am I doing wrong?

Can't I have a thread which is always running? When the app is removed, that thread is stopped by the corresponding event in my ServletContextListener.

I really do need something that keeps on checking the queue without delay.

Thanks a lot for any help!

Edit: This is the stack trace

GlassFish: deploy is failing=
    java.util.concurrent.TimeoutException
    at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
    at java.util.concurrent.FutureTask.get(Unknown Source)
    at com.sun.enterprise.jst.server.sunappsrv.SunAppServerBehaviour.publishDeployedDirectory(SunAppServerBehaviour.java:710)
    at com.sun.enterprise.jst.server.sunappsrv.SunAppServerBehaviour.publishModuleForGlassFishV3(SunAppServerBehaviour.java:569)
    at com.sun.enterprise.jst.server.sunappsrv.SunAppServerBehaviour.publishModule(SunAppServerBehaviour.java:266)
    at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:948)
    at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:1038)
    at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:872)
    at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:708)
    at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2690)
    at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:272)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

My Code:

public class BidPushThread extends Thread {
    private ServletContext sc=null;
    @Override
    public void run() {
        if (sc!=null){
            final Map<String, List<AsyncContext>> aucWatchers = (Map<String, List<AsyncContext>>) sc.getAttribute("aucWatchers");
            BlockingQueue<Bid> aucBids = (BlockingQueue<Bid>) sc.getAttribute("aucBids");

              Executor bidExecutor = Executors.newCachedThreadPool(); 
              final Executor watcherExecutor = Executors.newCachedThreadPool();
              while(true)
              {  
                 try // There are unpublished new bid events.
                 {
                    final Bid bid = aucBids.take();
                    bidExecutor.execute(new Runnable(){
                       public void run() {
                          List<AsyncContext> watchers = aucWatchers.get(bid.getAuctionId()); 
                          for(final AsyncContext aCtx : watchers)
                          {
                             watcherExecutor.execute(new Runnable(){
                                public void run() {
                                   // publish a new bid event to a watcher
                                   try {
                                    aCtx.getResponse().getWriter().print("A new bid on the item was placed. The current price "+bid.getBid()+" , next bid price is "+(bid.getBid()+1));
                                } catch (IOException e) {
                                    // TODO Auto-generated catch block
                                    e.printStackTrace();
                                }
                                };
                             });
                          }                           
                       }
                    });
                 } catch(InterruptedException e){}
              }

        }
    }
    public void setServletContext(ServletContext sc){
        this.sc=sc;
    }
}

Sorry for the formatting mess but for the life of my "indent code by 4 spaces" just does not work for me Edit: Read about 'BlockingQueue' and implemented it, but I'm still getting the exact same exception and stack trace. changed the above code to reflect the use of 'BlockingQueue'

Solution 1

Your code does not start a new thread, it runs the loop in the same thread and this is why you are getting a timeout error when deployed.

To start a thread you must call the start method, not the run method.

public void contextInitialized(ServletContextEvent sce) {   
//Some init code not relevant, omitted for clarity
  BidPushThread t= new BidPushThread();
  t.setServletContext(sce.getServletContext());
  t.start();// run();
}

Solution 2

setDaemon

SUMMARY:

• Marks this thread as either a daemon thread or a user thread. The Java Virtual Machine exits when the only threads running are all daemon threads.
• This method must be called before the thread is started.
• This method first calls the checkAccess method of this thread
  with no arguments. This may result in throwing a SecurityException (in the
  current thread).

Threads

SUMMARY: In many cases, what we really want is to create background threads that do simple, periodic tasks in an application. The setDaemon() method can be used to mark a Thread as a daemon thread that should be killed and discarded when no other application threads remain. Normally, the Java interpreter continues to run until all threads have completed. But when daemon threads are the only threads still alive, the interpreter will exit.

Solution 3

This would be a very bad idea. You'd cause a 100% CPU load without a good reason.

The correct solution is probably to block the thread when the queue is empty. This is trivially implemented with a BlockingQueue.

Solution 4

Can't I have a thread which is always running? When the app is removed, 
that thread is stopped by the corresponding event in my ServletContextListener.

"That thread is stopped"? How? There is no termination condition in your while(true) {...} loop. How are you stopping it? Are you using the Thread.stop() method? That is unsafe and was deprecated way back in Java 1.1

If you use setDaemon(true), the thread will stay active after you have stopped the web-app using your app-server's management tools. Then if you restart the web-app, you'll get another thread. Even if you attempt to undeploy the web-app, the thread will stay running and will prevent the entire web-app from being garbage-collected. Then redeploying the next version will give you an additional copy of everything in memory.

If you provide an exit condition for the loop (e.g. InterruptedException or a volatile "stopNow" boolean), you can avoid this issue.

View more solutions

Comments

[Ittai]

and what is the response time for that? I mean this is not implemented with sleep() but the 'BlockingQueue' itself wakes the thread up if I understand correctly, so is that immediate?

[MSalters]

Response time would be dominated by the OS thread scheduler. The waiting thread is blocked at OS level. When the queue becomes filled, the OS is signalled. At that point the thread is changed from waiting to runnable, and if a CPU/core is available at that time the thread is probably run immediately. Because it has been waiting it will likely get a priority boost, too.

[Tim Bender]

On a windows system, wait time from a block could be as much as 10 milliseconds, on a unix system much less.

[Ittai]

I'm sorry I can't accept two answers but In reality both you and MSalters were right, I needed to fix both Mistakes in order for the problem to be solved. I gave you a one up anyways, thanks for the effort.

[Ittai]

Wow, you are absolutely right! I changed it to start earlier with changing it to Daemon thread "just because" as they say and it started to work and I didn't realize it was due to that. (I now tested and this is what was stopping me). Thanks a million.

[Serxipc]

I've recently made the same mistake :-(

[Adrian Pronk]

Ha! Well spotted. Just the sort of thing that they could put into those silly Java tests: have a snippet that calls Thread.run() instead of Thread.start() and ask "What is wrong with this code?"