Print

[nkushman]

Hello,

My basic question is the same as that from:

http://www.jppf.org/forums/index.php?topic=1172.0

however that topic is really old so I'm starting a new one.

The basic issue that I'm having is that my tasks are timing out before they even begin to run.  That post talks about the timer starting when the bundle is handed to the node, but then references a bug to fix this behavior so that the timer starts when the task actually starts to run:

http://sourceforge.net/p/jppf-project/bugs/122/

This bug has subsequently been closed as fixed (status closed-fixed), however I'm still seeing the same problem.  My tasks timeout before they even begin to run (this is with only a task timeout set, and no job timeout set).

As alluded to in the other thread, I can solve this problem using the nodethreads load balancing model and setting the multiplier to 1.  However, since my jobs have a large number of short tasks (typically on the order of 1-100ms)  this completely kills the performance.

FWIW, I'm running version 3.1.4.

So I have three questions:

1.  Is this still the expected behavior, or was this problem supposed fixed when that bug was closed?

2.  Do you have any other suggested workarounds which wouldn't be such a performance killer?  I have to have some way of timing out my tasks, since some of my times will run forever if I let them.

3.  (only vaguly related) Is it correct that when a timeout occurs, the result for the task is set to null, even if a result is also set in the run method.  Additionally, the only way to detect a timeout is to check for this null result value, correct?

Thanks much for your help on this.

-Nate

[lolo]

Hello Nate,

Indeed, the bug report is clear enough, however the behavior it describes was not implemented. It is clear that we did not properly test it. I apologize for the inconvenience.
Therefore I registered a new bug report (on our new issue tracker): JPPF-117 Task timeout is not working as expected

Is there any chance that you could upgrade to the latest release, JPPF 3.2.1? That would make things easier and much shorter to deliver a patch for this issue.

Regarding your other questions:

Do you have any other suggested workarounds

I don't see anything as simple as changing the load-balancer configuration. If you really need a timeout mechanism quickly, you will have to implement it yourself while waiting for a fix, for example by running a Timer (e.g. from a node startup class) that will call Thread.interrupt() on the thread running the task (which means getting a hold of the thread in the run() method). However that could be a little complex.

Is it correct that when a timeout occurs, the result for the task is set to null

As far as I know (I checked the code for this), this is not what happens. If getResult() returns null, it means the result has not yet been set.

the only way to detect a timeout is to check for this null result value, correct?

The best way is to override the callback method JPPFTask.onTimeout() and write your own timeout handling code in it.

Sincerely,
-Laurent

[nkushman]

Laurent,

Thanks for your help.  I can move to 3.2.1 easily enough if that means you can get me a patch for this problem.

I'm currently hacking around it without all the thread business by using calls to System.nanoTime in my inner loop, but it's a real pain because I have to manually tune the # of loop iterations it go between calls to nanoTime to ensure that it doesn't kill my performance.  So it would be great to have a "real" solution.

As for the null return value problem, it looks like your suggested solution works.  I was catching the InterruptedException inside my run method, and then calling setResult or setException from the run method, without overriding the onTimeout method.  In this case, any of my calls to setResult and setException were overwritten to null in the case of a timeout.  It might be worth documenting this a bit more clearly (or changing the behavior) since I've seen other people in the forums who ran into the same confusion.

Thanks a ton for your help.

-Nate

[lolo]

Hi Nate,

Thanks for accepting to upgrade. I have published a patch, which you can get from here.

Please let us know if this resolves the problem for you.

-Laurent