Creating a Timeout on a method

[John A. Bailo]

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?

 

[ricky.clarkson]

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.

 

[John Bailo]

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.

 

[Mike Schilling]

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.

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.

 

[John Bailo]

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?

 

[Mike Schilling]

Would I run the timer on the main thread?

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.

 

[Thomas Weidenfeller]

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

 

[ricky.clarkson]

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()

 

[Thomas Weidenfeller]

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:

/Thomas

 

[John A. Bailo]

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...

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.

 

[John A. Bailo]

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()

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.

 

[John A. Bailo]

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?

 

[Andrea Desole]

return the thread to your pool. The app as a whole may be in a corrupted
state,

That's of course a minor detail

 

[Mike Schilling]

That's of course a minor detail

Well, you fix what you can and ignore what you can't

 

[Alun Harford]

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

 

[John Bailo]

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.

 

[Chris Uppal]

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

 

[John A. Bailo]

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.

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."