«

all,

I have problem with a third party module that I'm using - the methods
inside it tend to freeze (ie: go away and not come back). The problem
is intermittent, and can happen in more than one method in the module.

The way I look at it, I've got only one choice as it stands; to run
the commands in a separate thread, and have the parent thread kill the
child thread if it hasn't exited within a certain interval. But this
is messy, not only from the extra code that I'm going to have to
write, but from

a) the need to use data from the child in the parent
b) the need for retry in case of failure
c) the need to handle any cleanup from the child.

So I was hoping that there was some support for timeouts in methods,
something like:

public String[] method(int input, int input2) throws
TimeoutException(60000)
{
...
...
}

which would handle all of the timeout and data issues for a given
function call, and throw a timeout exception if it hits 60 seconds (in
this case).

Anyways, I know something like this doesn't exist in the form stated
above, but anything remotely like it would be most welcome. Otherwise,
is there an API which handles this effectively? I'm at a loss on how
to do this cleanly..

Thanks much,

Ed

horos11 wrote:
> all,
>
> I have problem with a third party module that I'm using - the methods
> inside it tend to freeze (ie: go away and not come back). The problem
> is intermittent, and can happen in more than one method in the module.
>
> The way I look at it, I've got only one choice as it stands; to run
> the commands in a separate thread, and have the parent thread kill the
> child thread if it hasn't exited within a certain interval. But this
> is messy, not only from the extra code that I'm going to have to
> write, but from
>
> a) the need to use data from the child in the parent
> b) the need for retry in case of failure
> c) the need to handle any cleanup from the child.
>
> So I was hoping that there was some support for timeouts in methods,
> something like:
>
> public String[] method(int input, int input2) throws
> TimeoutException(60000)
> {
> ...
> ...
> }
>
> which would handle all of the timeout and data issues for a given
> function call, and throw a timeout exception if it hits 60 seconds (in
> this case).
>
> Anyways, I know something like this doesn't exist in the form stated
> above, but anything remotely like it would be most welcome. Otherwise,
> is there an API which handles this effectively? I'm at a loss on how
> to do this cleanly..

There's no declarative structure for that in Java.

Timeout thread coding is tricky but pretty much necessary here. If you snoop
around the java.util.concurrent package there are some mechanisms that can help.

For example, if you set up your method call in a cancellable thread, you can
use Future/FutureTask#get(long timeout, TimeUnit unit) to retrieve the result.

--
Lew

> There's no declarative structure for that in Java.
>
> Timeout thread coding is tricky but pretty much necessary here. If you snoop
> around the java.util.concurrent package there are some mechanisms that can help.

How about this -

If I make a timer object around the thrid party code that is causing
all the trouble, and set a timeout task to be called on the current
thread, won't an interrupt exception be generated? ie: something like
this:

class TimeoutMe extends TimerTask
{
Thread thr;

TimeoutMe(Thread thr)
{
this.thr = thr;
}

public void run()
{
if(thr.isAlive())
{
thr.interrupt();
}
}
}


class MyClass
{

Timer timer = new Timer();
....


public String method() throws InterruptedException
{
timer.schedule(new TimeoutMe(Thread.currentThread()), 10000);
....
timer.cancel();
}

Won't this work in the way I'm describing, ie: interrupting the thread
(without killing it) and allowing it to throw an exception gracefully?

As I see it, this is clean in the sense that there are no extra
threads, and hence no need for the handling of data between them, but
I'd be interested to hear any drawbacks in doing this.

Ed

horos11 wrote:
> all,
>
> I have problem with a third party module that I'm using - the methods
> inside it tend to freeze (ie: go away and not come back). The problem
> is intermittent, and can happen in more than one method in the module.
>
Well, it sounds like the module has bugs in it.
Is it possible to have those bugs repaired?

Is your app already multi-threaded? Are you properly synchronizing while
using the third-party module? Does it claim to be thread-safe?

It *sounds* like a dead-lock issue. Try doing a thread-dump when the
method hangs.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

On Sep 1, 9:01*pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
> horos11 wrote:
> > all,
>
> > I have problem with a third party module that I'm using - the methods
> > inside it tend to freeze (ie: go away and not come back). The problem
> > is intermittent, and can happen in more than one method in the module.
>
> Well, it sounds like the module has bugs in it.
> Is it possible to have those bugs repaired?
>

No, I don't have the source to do this..

> Is your app already multi-threaded? Are you properly synchronizing while
> using the third-party module? Does it claim to be thread-safe?
>
> It *sounds* like a dead-lock issue. *Try doing a thread-dump when the
> method hangs.
>

Well, also, no, it doesn't look like a deadlock issue. There is only
one thread showing up, and it is stuck in a waitloop.
More likely it's an infinite loop that wasn't properly handled.

Anyways, I don't see anything wrong (at first blush) with using the
Timer/interrupt hack to get around this. It really does involve
another
thread (the timer thread) but at least I don't need to do extra thread
management..

Ed

On Tue, 1 Sep 2009 18:31:59 -0700 (PDT), horos11 <>
wrote, quoted or indirectly quoted someone who said :

>Anyways, I know something like this doesn't exist in the form stated
>above, but anything remotely like it would be most welcome. Otherwise,
>is there an API which handles this effectively? I'm at a loss on how
>to do this cleanly.

The other way to face this is to figure out how to dump interesting
information about what happened just prior to the freezeup so you can
fix whatever is causing it.

It might be considered "malpractice" to put out code into the world
that relied on such a mechanism as you propose.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

> It might be considered "malpractice" to put out code into the world
> that relied on such a mechanism as you propose. *
> --

In a world where everyone has access to code and is able to make a
change and/or fix, or where you have the freedom to change horses in
midstream, this statement would be true.

Otherwise, you cope, and make sure that in the case of an exception
that the exception is recoverable.

Ed

horos22 wrote:
>> It might be considered "malpractice" to put out code into the world
>> that relied on such a mechanism as you propose.
>> --
>
> In a world where everyone has access to code and is able to make a
> change and/or fix, or where you have the freedom to change horses in
> midstream, this statement would be true.
>
> Otherwise, you cope, and make sure that in the case of an exception
> that the exception is recoverable.
>
> Ed

What does this third part package provide?
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Ken T. wrote:
> Coding a timeout isn't really that hard, despite what Lew says earlier in
> the thread. Start a thread in the method that calls the library to
> actually do the call. When it gets done send a notify. In the code that
> starts the thread, do a wait with a timeout. If the wait expires due to
> the timeout, the method has timed out. If it gets the notify continue
> normally. There are some caveats, but it isn't that hard.
>
> Are you familiar enough with wait and notify to do this yourself?

All I said was that it's tricky, as indeed it is. Tricky doesn't exactly mean
hard, it means that if you get certain things wrong that they go wrong in a
big way. For example, if you do wait and notify on the wrong monitors this
technique will fail utterly. If you don't synchronize the shared data that
represents the method return, if any, then you might never publish the result
back to the calling thread. Worse, you might not discover this in testing if
the hardware differs from the deployment platform or other conditions differ,
due to the non-deterministic nature of thread bugs.

Tricky stuff.

--
Lew

horos22 wrote:
>> It might be considered "malpractice" to put out code into the world
>> that relied on such a mechanism as you propose.
>> --
>
> In a world where everyone has access to code and is able to make a
> change and/or fix, or where you have the freedom to change horses in
> midstream, this statement would be true.
>
> Otherwise, you cope, and make sure that in the case of an exception
> that the exception is recoverable.


Nevertheless, I think we'd all be interested in hearing which package
you are having trouble with. We might have to use it some day, and it
would be great to be fore-warned of any potential problems.

An SSCCE would be even better. A timer might be a good quick fix but
someone might be able to debug this fully for you, if we had any clue
what was happening.