Both work, except when the first one doesn't. Why does it fail?
posted 3 years ago
The first one uses Future objects. This allows me to place a timeout on each object with the 'Future.get' function. This is nice but adds a bit of variability in the code. I don't know if it will take seconds to run the request or hours or days. It really doesn't matter because after 1000 objects are created, it begins to get flaky. About 10% of the time Apache kills the parent process (a Perl CGI script), and thus killing the child process (the forked Java process).On the other hand, I can control the timeout of the entire executor and force it to timeout before Apache's hard timeout of 10 minutes (set in the Apache config). This way I can ensure proper cleanup before Apache gives it the axe. I would love to incorporate both timeouts. However, the bit of code above dies after 2-3 minutes (~1000 callableObjects) 10% of the time and cannot be trusted.
Apache Errors for the first bit of code:
[error] [client <IP Address>] \tat java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:258), referer: http://my.box.net/code/UI.pl [error] [client <IP Address>] \tat java.util.concurrent.FutureTask.get(FutureTask.java:119), referer: http://my.box.net/code/UI.pl [error] [client <IP Address>] \tat Thread_Handler.setupThreads(Thread_Handler.java:38), referer: http://my.box.net/code/UI.pl [error] [client <IP Address>] \tat <Java Main>.main(<Java Main>.java:72), referer: http://my.box.net/code/UI.pl
Question 1: What is wrong with the first bit of code to cause it to be unstable? Is this a bug in Java or my ignorance?
Question 2: Why is the second bit of code stable? I really see no difference as long as the total time to run is under 10 minutes.
Question 3: Is there a better way to do this whole idea?