Removing Thread blocks

[Selvakumar Dharmaraj]

Hi,
In my application I am starting a java.lang.Timer Thread to fetch the mails from the mail server. The thread will be started in the server startup process. The thread call it's run method at a periodic interval and the method itself call a another method to fetch mails from the mail server.
problem arise here, that the method establishing the connection with the mail server and some times goes for dead because of poor band width.
To avoid I have written a monitor thread to look for this thread, If the thread goes for dead more then 10min then this thread will kill the mail thread and restart it agin.

but, even the monitor thread restarts the mail thread, the mail thread may not be able to establish the connection and again going for the dead.
(using timer.cancel() method...)
If I restarts the server it fetching the mails properly.
Please help me to solve this problem,
selva.

  
public SplitAttachments()
{
timer = new Timer();
timer.schedule(new RepeatedTask(),0,60000);
}

class RepeatedTask extends TimerTask
{
public void run()
{
     SplitAttachments.readMail();
}
}
public static void readMail()
{
try
{
isTimerAlive = false;
Properties props = new Properties();
Session session = Session.getInstance(props, null);
Store store = session.getStore("pop3");
//AFTER THE FOLLOING LINE EXECUTED THE THREAD GOES FOR DEAD
store.connect(CDataTransferBL.sHost,CDataTransferBL.sUser,CDataTransferBL.sPassword);

POP3Folder folder = (POP3Folder)store.getFolder("INBOX");
folder.open(Folder.READ_WRITE);
--------------
------------
}

[David Weitzman]

If store.connect() blocks, you're pretty much restricted to calling Thread.interrupt() and hoping that store.connect() is written in a way which causes that to do something (which is not specified in the API docs). You could always call Thread.stop(), but then you risk being impaled by the programming gods.
So try this (warning: this code is untested):

  // ...
  Store store = session.getStore("pop3");
  threadStartsBlocking();
  try {
    //AFTER THE FOLLOING LINE EXECUTED THE THREAD GOES FOR DEAD
    store.connect(CDataTransferBL.sHost,CDataTransferBL.sUser,CDataTransferBL.sPassword);
  } finally {
    threadStopsBlocking();
  }
  POP3Folder folder = (POP3Folder)store.getFolder("INBOX");
  // ...

threadStartsBlocking() will start waiting for the task to complete. If it doesn't complete within a certain time range, it will be interrupted. Completion is marked by calling threadStopsBlocking(). Here is the code for those two methods. It's designed to only support monitoring a single Thread, although it could be expanded using Maps to support multiple threads.

  boolean finished;
  final Object monitor = new Object();
 
  void threadStartsBlocking() {
    final Thread blockingThread = Thread.currentThread();
    synchronized(monitor) {
      finished = false;
    }
 
    new Thread() {
      public void run() {
        synchronized(monitor) {
          // sleep until we're notify()ed or 10 seconds pass.
          // We have some code here to insure that being notified too
          // early doesn't cause problems (there are other ways to accomplish
          // the same thing, but this is a pretty robust one). We'll be notified
          // too early if the tasks finishes quickly and threadStopsBlocking()
          // calls notify() when nothing is wait()ing, or if we share monitors
          // for whatever reason.
 
          long finishTime = System.currentTimeMillis() + 10000;
          long now;
          while (!finished && (now = System.currentTimeMillis()) < finishTime)
            moniter.wait(finishTime - now);
 
          if (!finished) {
            activeThread.interrupt();
            finished = true;
          }
        }
      }
    }.start();
  }
 
  void threadStopsBlocking() {
    synchronized(monitor) {
      finished = true;
      monitor.notify();
    }
  }

Assuming Store is blocked on standard IO, interrupting will probably work -- but it isn't guaranteed. Good luck.

[Jim Yingst]

I assume we're talking about javax.mail.Store and javax.mail.Session? From the docs, it looks like the problem may be that you're attempting to connect() the same Store twice, which is an error. (See inherited API for Service. It's hard to tell though, because when you call getStore(), it's unspecified whether you get a new Store object or a preexisting one, which may already be open (or not). I'd recommend calling isConnected() before you connect, to see if it's necessary. You might also try adding a ConnectionListener to the Store to get additional info on what happens to that connection later:

public class ConnectionLogger implements ConnectionListener {
    public void closed(ConnectionEvent ce) {
        logEvent("closed", ce);
    }
    public void disconnected(ConnectionEvent ce) {
        logEvent("disconnected", ce);
    }
    public void opened(ConnectionEvent ce) {
        logEvent("opened", ce);
    }
    private void logEvent(String label, ConnectionEvent ce) {
        String msg = "Connection " + label + " (source=" + ce.getSource() + ")";
        // replace this line with whatever logging you're using:
        System.out.println(msg);
    }
}

Then, to get more info about whatever is going on:

if (!store.isConnected()) {
    store.addConnectionListener(new ConnectionLogger());
    store.connect();
}

You could also do something like this with a StoreListener, which may provide even more info. In fact you may find that the StoreListener sends you events when new mail arrives, which might mean you don't have to keep pinging the server, but instead wait for new events. That's just a wild guess though; quite possibly nothing like that will happen. But it might be worth investigating what StoreEvents there are, just to find out...
Also, I'm a bit confused by this line in your original code:

isTimerAlive = false;

Aside from the fact that there's no declaration shown for isTimerAlive, the fact is that at the time this code is called, the timer is alive. It's been set for repeated execution every 60 seconds - it's shouldn't be dying off just because it executes once. So I'm not sure what this variable is for, but it seems to indicate a misunderstanding of some sort.
Anyway, you may indeed need to try using Thread methods like interrupt() as DW suggest (or maybe even suspend() if you're really desparate, but I'd save that for a last resort). But I'd investifate other avenues first - seems like there's a good chance that you're just not connect()-ing in the right way. Good luck.
[ October 18, 2003: Message edited by: Jim Yingst ]

[Selvakumar Dharmaraj]

Thanks for your valuable suggestion.
I am trying with both option. I can not get immediate results with my production servers. Because of the bandwidth variation, some time the thread goes for dead or not.
I will update you, If i face any similar problem again with the threads.
---------------------------
isTimerAlive variable used by the monitor thread. While the mail fetching thead starts its process, sets its isTimerAlive value to false and while comes out will set again to true. If the monitoring thread finds the isTimerAlive value in false more than 10 mins, then it will cancel the mail thread and start again.
---------------------------