Limiting a function's runtime

E

Enter The

Hi,

Is there a way to limit how long a function runs for, similar to the
timeout property for URLConnection?

For example, the function is called getCompressedPrices(). It
occasionally fails to return anything and freezes my application.

I'm using an external package, and would prefer not to tinker with the
getCompressedPrices() function.

Regards,

Enter
 
M

Matt Humphrey

Enter The said:
Hi,

Is there a way to limit how long a function runs for, similar to the
timeout property for URLConnection?

For example, the function is called getCompressedPrices(). It
occasionally fails to return anything and freezes my application.

I'm using an external package, and would prefer not to tinker with the
getCompressedPrices() function.

There is very little you can do within a JVM to tame a badly behaved
function or thread. If an external library is unsafe a very reasonable
approach (depending on your performance needs) is to launch it in a separate
JVM (process), like a miniature server. (By leaving the server running you
save startup costs.) You can then make asynchronous requests of it and
accept timeouts. You could also monitor the health of that server
independently and restart it if it stops responding to requests. You could
probably build something quickly out of RMI.

Cheers,
Matt Humphrey http://www.iviz.com/
 
A

Are Nybakk

Enter said:
Hi,

Is there a way to limit how long a function runs for, similar to the
timeout property for URLConnection?

Hmm, here's an idea. You could create a thread that calls the function
and sets a status variable when it is done. Let main (or whatever mother
thread) sleep for a certain time and check the variable. If it didn't
finish, terminate the thread.
 
M

Matt Humphrey

Are Nybakk said:
Hmm, here's an idea. You could create a thread that calls the function and
sets a status variable when it is done. Let main (or whatever mother
thread) sleep for a certain time and check the variable. If it didn't
finish, terminate the thread.

Which raises the very interesting question: how do you safely terminate a
method or thread that is running code you cannot modify? Of course, if the
method is designed to be halted just follow its directions. I don't think
that's generally the case, however. Interrupt() typically only applies to
code that is waiting. Stop() and suspend () are deprecated and can leave
the system in an invalid state. They might work, but you won't know whether
they're safe.

Destroy () isn't implemented (according to Javadocs), which means it has the
same effect as ignoring the thread, but doing so allows potentially
deadlocked or CPU-bound code to consume resources or to incur further
problems with new tasks that are created (e.g. the broken code is holding
locks needed by additional requests.)

Knowing more about the code itself may lead to a technique just for that
code, like closing a socket or something, but generally there are no
techniques for safely stopping 3rd party code. If it really has to be safe,
put it in a separate process.

Cheers,
Matt Humphrey http://www.iviz.com/
 
R

Roedy Green

Which raises the very interesting question: how do you safely terminate a
method or thread that is running code you cannot modify?

you can't. The method to do it is deprecated. If you try to kill it
gently, the killed thread must co-operate. If it has gone insane, it
may be in on position to co-operate.

see com.mindprod.common11.StoppableThread bundled in
http://mindprod.com/products1.html#COMMON11
 
A

Are Nybakk

Matt said:
Which raises the very interesting question: how do you safely terminate a
method or thread that is running code you cannot modify? Of course, if the
method is designed to be halted just follow its directions. I don't think
that's generally the case, however. Interrupt() typically only applies to
code that is waiting. Stop() and suspend () are deprecated and can leave
the system in an invalid state. They might work, but you won't know whether
they're safe.

Yes I noticed the deprecations. That was new to me. I see the API links
to a page which describes some alternative methods to halt a thread:

http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
 
M

Matt Humphrey

Are Nybakk said:
Yes I noticed the deprecations. That was new to me. I see the API links to
a page which describes some alternative methods to halt a thread:

http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

Those notes show how to design or refactor a method or thread so that it can
be stopped, but if you already have a method that is not well-behaved and
cannot be rewritten you're out of luck. Wrapping a non-stoppable method
with one that is stoppable will not produce a stoppable method.

Matt Humphrey http://www.iviz.com/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,834
Latest member
BuyCannaLabsCBD

Latest Threads

Top