how to manage timeout in java

[Pif]

Hello,

I must call java method that does not support timeout feature.
I would like to be able to manage timeout on this method.

I'm in JDK 1.4.2 in a multi-user environment. So I would prefer not
using one thread for each call. Can you suggest me solutions, ideas,
or existing librairies ?

Thanks a lot.

 

[John B. Matthews]

Hello,

I must call a Java method that does not a support timeout feature.
I would like to be able to manage a timeout on this method.

I'm in JDK 1.4.2 in a multi-user environment. So I would prefer not
using one thread for each call. Can you suggest solutions, ideas,
or existing librairies?

Well, you have to invoke the method from _some_ thread. You might look
to see if the SwingWorker back-port is viable on 1.4.2.

 

[Lew]

"So" you would prefer not to use a separate thread for each call? How does
that follow?

You should spawn the call in a separate thread and let that thread handle the
timeout interrupt.

Well, you have to invoke the method from _some_ thread. You might look
to see if the SwingWorker back-port is viable on 1.4.2.

Assuming we're dealing with a Swing app.

There is a backport of java.util.concurrent available for 1.4. GIYF.

Why are you using an obsolete version of Java? The End-of-Life (EOL) period
for 1.4 has expired and Sun no longer supports it.

On October 30, 2008 J2SE 1.4.2 reached the end of its service life (EOSL).

Java 1.4 is nearly seven years old, eons in I.T. years. Even Java 5, over
four years old itself, is in its EOL already.

For God's sake, upgrade!

 

[John B. Matthews]

[...] So I would prefer not using one thread for each call. Can
you suggest solutions, ideas, or existing librairies?

"So" you would prefer not to use a separate thread for each call? How does
that follow?

You should spawn the call in a separate thread and let that thread handle the
timeout interrupt.

Well, you have to invoke the method from _some_ thread. You might look
to see if the SwingWorker back-port is viable on 1.4.2.

Assuming we're dealing with a Swing app.

Excellent point. I see there's a new version, 1.2, as of July 25, 2008.

There is a backport of java.util.concurrent available for 1.4. GIYF.

Thank you, good to know. I only recently wrapped-up my last 1.4.2
project, but you never know. Some of the best paying clients are the
most cuncatory about upgrades.

[...]

 

[Lew]

Thank you, good to know. I only recently wrapped-up my last 1.4.2
project, but you never know. Some of the best paying clients are the
most cuncatory about upgrades.

"Cuncatory" sounds so dirty.

I don't find it in the dictionaries I have at hand. Could you define it,
please, and provide a reference?

At this point, if a client is "best-paying" and therefore presumably not
unnecessarily stingy, they really should consider the risk of operating on an
unsupported product. It's much higher now and increasing, even ignoring the
manifest benefits of Java 5 and later.

If they are running multi-threaded code, then they really have much higher
risk with 1.4, given that it has the less mature and arguably incorrect memory
model. Simply using the 1.4.2 version of java.util.concurrent isn't going to
fix that.

 

[John B. Matthews]

"Cuncatory" sounds so dirty.

I don't find it in the dictionaries I have at hand. Could you define it,
please, and provide a reference?

I'd be delighted:

<http://en.wiktionary.org/wiki/cunctatory>

C.f. Fabius Maximus:

At this point, if a client is "best-paying" and therefore presumably not
unnecessarily stingy, they really should consider the risk of operating on an
unsupported product. It's much higher now and increasing, even ignoring the
manifest benefits of Java 5 and later.

They move, albeit slowly. EOL is a motive. I am heartened that it's
relatively easy to build and test against several versions on the same
development system.

 

[John B. Matthews]

And misspelled, something I managed to do even after looking it up.

I'd be delighted:

<http://en.wiktionary.org/wiki/cunctatory>

[...]

 

[oliver789]

Maybe this is of interest: "Hashed and Hierarchical Timing Wheels" by
Varghese (http://citeseer.nj.nec.com/varghese96hashed.html)

Regards, Oliver

 

[Roedy Green]

Well, you have to invoke the method from _some_ thread. You might look
to see if the SwingWorker back-port is viable on 1.4.2.

The basic idea is you need two threads, one to do the work, and one to
wake up later and see if the first has completed as expected and if
not, take evasive action.

If you have a number of these to do, you can use a shared Timer to
monitor timeouts on all the worker tasks.

See http://mindprod.com/jgloss/thread.html
http://mindprod.com/jgloss/timer.html

This would be a good time to order a copy of Java Concurrency In
Practice, in case you get stuck.

http://www.amazon.com/gp/product/03...mp=1789&creative=9325&creativeASIN=0321349601

--
Roedy Green Canadian Mind Products
http://mindprod.com
"Humanity is conducting an unintended, uncontrolled, globally pervasive experiment
whose ultimate consequences could be second only to global nuclear war."
~ Environment Canada (The Canadian equivalent of the EPA on global warming)