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.
Joined: Jul 27, 2001
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):
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.
Assuming Store is blocked on standard IO, interrupting will probably work -- but it isn't guaranteed. Good luck.
Joined: Jan 30, 2000
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:
Then, to get more info about whatever is going on:
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:
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 ]
"I'm not back." - Bill Harding, Twister
Joined: Dec 12, 2002
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. ---------------------------