Limiting a function's runtime

Thread view:

Enter The - 08 Nov 2007 15:56 GMT

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

Reply to this Message

Matt Humphrey - 08 Nov 2007 17:46 GMT

> Hi,
>
[quoted text clipped - 6 lines]
> 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/

Reply to this Message

Are Nybakk - 08 Nov 2007 19:38 GMT

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

> For example, the function is called getCompressedPrices(). It
> occasionally fails to return anything and freezes my application.
[quoted text clipped - 5 lines]
>
> Enter

Reply to this Message

Matt Humphrey - 08 Nov 2007 21:17 GMT

>> Hi,
>>
[quoted text clipped - 5 lines]
> 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/

Reply to this Message

Roedy Green - 09 Nov 2007 00:07 GMT

>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

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Are Nybakk - 09 Nov 2007 14:18 GMT

>>> Hi,
>>>
[quoted text clipped - 12 lines]
> 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/threadPrimitiveDe
precation.html

> Destroy () isn't implemented (according to Javadocs), which means it has the
> same effect as ignoring the thread, but doing so allows potentially
[quoted text clipped - 9 lines]
> Cheers,
> Matt Humphrey http://www.iviz.com/

Reply to this Message

Matt Humphrey - 09 Nov 2007 17:16 GMT

>>>> Hi,
>>>>
[quoted text clipped - 17 lines]
>
> http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDe
precation.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/

Reply to this Message

Limiting a function's runtime

Free Magazines