how to manage timeout in java
Pif
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
<f9768762-ebcf-4fc3...@l39g2000yqn.googlegroups.com>,
Pif <fjs...@laposte.net> wrote:
> 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.
--
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/
Lew
Pif wrote:
>> 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?
"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.
John B. Matthews wrote:
> 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.
<http://java.sun.com/j2se/1.4.2/download.html>
> 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!
--
Lew
John B. Matthews
> Pif wrote:
> >> [...] 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.
>
> John B. Matthews wrote:
> > 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.
--
Lew
John B. Matthews
> John B. Matthews wrote:
> > 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?
I'd be delighted:
<http://en.wiktionary.org/wiki/cunctatory>
C.f. Fabius Maximus:
<http://en.wikipedia.org/wiki/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.
> 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
"John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <ggnhh5$mo5$1...@aioe.org>, Lew <no...@lewscanon.com> wrote:
>
> > John B. Matthews wrote:
> > > 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.
And misspelled, something I managed to do even after looking it up.
> > 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>
[...]
--
John B. Matthews
"What a dictionary this is. You have to know how something is spelt
before you can look it up to see how it's spelt."
--Annie Sullivan, The Miracle Worker (1962).
oliv...@web.de
Varghese (http://citeseer.nj.nec.com/varghese96hashed.html)
Regards, Oliver
Roedy Green
<nos...@nospam.invalid> wrote, quoted or indirectly quoted someone who
said :
>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.
--
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)