 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005Creating a Timeout on a method
I call a method is part of an external API. This method has no timeout parameter on it. I need to be able to control the maximum time it can try -- or else it hangs my app. This method is called each time on a thread. Suggestions? All methods are called 'on a thread'. Be more specific. I would choose not to use this external API, or dedicate a thread to it. Only one thread, otherwise you start leaking threads. Then when it hangs, you can safely restart your app from another thread. > All methods are called 'on a thread'. Be more specific. Ok. I create a thread pool from my main. In the run method of my threaded class, in each thread of the thread pool, I call this external API. I want to add a timeout to each thread, so that if this method call takes longer than a certain time, it releases the thread back into my thread pool. > I would choose not to use this external API, or dedicate a thread to > it. Only one thread, otherwise you start leaking threads. Then when > it hangs, you can safely restart your app from another thread. >> All methods are called 'on a thread'. Be more specific. > [quoted text clipped - 6 lines] > longer than a certain time, it releases the thread back into my thread > pool. The best you can do is to use a timer of some sort (say, using java.util.Timer) and should the call still be active, interrupt the thread. Should the interrupt eventually come back to the caller of the method, return the thread to your pool. The app as a whole may be in a corrupted state, but at least the thread is available. > The best you can do is to use a timer of some sort (say, using > java.util.Timer) and should the call still be active, interrupt the thread. > Should the interrupt eventually come back to the caller of the method, > return the thread to your pool. The app as a whole may be in a corrupted > state, but at least the thread is available. Would I run the timer on the main thread? Or from the thread in the thread pool? Are you suggesting using an "ActionListener" of some sort to handle the timer tick event and then join() the thread to kill it? >> The best you can do is to use a timer of some sort (say, using >> java.util.Timer) and should the call still be active, interrupt the [quoted text clipped - 5 lines] > > Or from the thread in the thread pool? java.util.Timer creates its own thread. > Are you suggesting using an "ActionListener" of some sort to handle the > timer tick event and then join() the thread to kill it? Let's see: you'd assign each thread in the pool a sequence number (incremented each time you put it back in the pool), create a TimerTask with the thread object and number, and interrupt the thread if the task gets run and the sequence numbers match. Or something like that; I can'r claim to have thought through al the details. > return the thread to your pool. The app as a whole may be in a corrupted > state, That's of course a minor detail :-) >> return the thread to your pool. The app as a whole may be in a corrupted >> state, > > That's of course a minor detail :-) Well, you fix what you can and ignore what you can't :-) > I call a method is part of an external API. > > This method has no timeout parameter on it. > > I need to be able to control the maximum time it can try -- or else it > hangs my app. And what do you do if the timer expires? If you don't have a means to interrupt that method, or if you don't have reasonable hopes that it will terminate in a reasonable way in a reasonable time (e.g. no endless loop) by itself, what do you want to do? Then you are just sitting there with an expired timer, and some thread still executing that method. If you can afford the resources for that no-longer-needed but still running thread, it might work. You just let the thread run and ignore it. But if you need the resources just a timer will not help you. Then you need support from that method, a way to ask it to return prematurely. Your best bet is probably to talk to the supplier of the API and get some interface to stop the execution of that method in a controlled way. /Thomas  SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ You cannot safely do this. If you killed a method after a timeout, it would leave data in undefined states. See the documentation on Thread.stop() [1] to find out more on this issue. Personally I'd just use a different API, or consult the API vendor. [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#stop() > You cannot safely do this. If you killed a method after a timeout, it > would leave data in undefined states. You can very well prematurely terminate a method, if - and that was the point of my post - the method cooperates. I wrote "method" and not "thread" for a very good reason. I am well aware of the fact that Thread.stop() is a no-no. > Personally I'd just use a different API, or consult the API vendor. I though I said that: >> Your best bet is probably to talk to the supplier of the API /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > You can very well prematurely terminate a method, if - and that was the > point of my post - the method cooperates. I wrote "method" and not > "thread" for a very good reason. I am well aware of the fact that > Thread.stop() is a no-no. How about Thread.join() then? > You cannot safely do this. If you killed a method after a timeout, it > would leave data in undefined states. [quoted text clipped - 5 lines] > > [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#stop() That would be my preference, to use the new Thread pool classes in the 1.5, but I'm resticted to the 1.4 so I'm using a custom ThreadPool class. > Your best bet is probably to talk to the supplier of the API and get > some interface to stop the execution of that method in a controlled way. If you only knew this vendor... :D Seriously, this is a case where the API should be open sourced, so I can make the changes I need....and yes, in an ideal world, that would be the best way -- to catch the problem within the method. My own program/class is uses a thread pool, and it waits on active threads, so this method keeps one thread open and it cannot complete when this happens. > I call a method is part of an external API. > > This method has no timeout parameter on it. > > I need to be able to control the maximum time it can try -- or else it > hangs my app. My suggestion would be to contact the API vendor, or modify the source code and recompile it (or failing that modify the bytecode) - assuming there are no legal constraints. I suppose there is one (bad) way to do it (assuming you've got permission): Create a new Java program that calls your method for you, opens a socket to you and passes you the result. Run that in a seperate JVM and if it hangs, kill -9 the process. It's messy, slow and probably unreliable, but it's the only way I can think of to safely do the job. Alun Harford > I suppose there is one (bad) way to do it (assuming you've got permission): > Create a new Java program that calls your method for you, opens a socket to > you and passes you the result. Run that in a seperate JVM and if it hangs, > kill -9 the process. > It's messy, slow and probably unreliable, but it's the only way I can think > of to safely do the job. That's a great idea. If I encapsulate it in a web method -- that would have it's own built in timeout. > I suppose there is one (bad) way to do it (assuming you've got > permission): Create a new Java program that calls your method for you, > opens a socket to you and passes you the result. Run that in a seperate > JVM and if it hangs, kill -9 the process. > It's messy, slow and probably unreliable, but it's the only way I can > think of to safely do the job. Agreed that it's messy, but it would be nowhere near as unreliable as any of the alternatives. As to slowness, any slowdown would come from communication overhead (probably not large, I'd /guess/), and the delay in starting the slave JVM. That problem (if it is a problem) could be eliminated by running the slave as a long-running server which accepts requests and supplies answers. It still kills itself (no need for kill -9) if it finds it's taking too long to service a request, but under normal circumstances it keeps running. More complex to implement, of course, but perhaps not /that/ much more complicated. -- chris > Agreed that it's messy, but it would be nowhere near as unreliable as any of > the alternatives. As to slowness, any slowdown would come from communication [quoted text clipped - 4 lines] > service a request, but under normal circumstances it keeps running. More > complex to implement, of course, but perhaps not /that/ much more complicated. Here's the suggestion of one person: http://www.javacoffeebreak.com/articles/network_timeouts/ "I've identified two relatively simple solutions to the problem of handling network timeouts. The first solution involves the use of second thread, which acts as a timer. This solution results in a slight increase in complexity, but is backwards compatible with JDK1.02. The second solution is by far, much simpler. It takes only a few lines of code, by setting a socket option, and catching a timeout exception. The catch is, that it requires a JDK1.1 or higher virtual machine." Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.