On 06/18/2015 02:25 PM, John Arthorne
wrote:
Hi Mickael,
Take a look at the Javadoc for
Job#join
methods, they describe in detail why this is not permitted.
Essentially
it is a high deadlock risk when combined with job pool
throttling.
Thanks, I didn't look in the Javadoc, which contains a good
explanation.
I'd advocate that a deadlock is always possible with a join in any
case, and that I don't think the API has to be so limiting.
Actually, I anticipated this potential deadlock issue because of
missing threads for the group in the code and used some guards to
avoid deadlocks.
if (jobGroup.getMaxThreads() == 0 ||
jobGroup.getActiveJobs().size() < jobGroup getMaxThreads()) {
crawlerJob.setJobGroup(jobGroup);
crawlerJob.schedule();
} else {
crawlerJob.run(); // run in current thread to avoid deadlock
waiting for a new thread
}
Also, I am 100% sure that as long as I have more threads than the
"depth" of the folder it crawls, there will be no deadlock.
In such condition where the developer has some assumption about the
ability to safely throttle and call join in a job group, is there a
way to bypass this check?
|