We have a build target which runs several concurrent builds inside of a parallel block. This target would intermittently through several NPE's and fail. Long story short, I chased the NPE's back to the DirectoryScanner class. In looking at the class it was clear that there several methods which modified the same member, and had no locking in place to prevent concurrent modification of that member. Since applying the attached patch, we have not seen this error (several hundred builds later). Whereas without the patch, we see the failure in at least 1 out of every 10 builds.
Created attachment 27939 [details] patch for DirectoryScanner.java
Your patch synchronizes access to the default excludes - which may be a good thing to do in any case - which implies the tasks you are running in parallel are modifying the default excludes. How can you ensure consistent results? About your patch, I probably wouldn't make defaultExcludes volatile but rather final (and rewrite the reset method to clear the set rather than create a new one) - in particular since you are synchronizing on it. Did you really have to make isExcluded and isSelected synchronized? These instance methods shouldn't be used by multiple threads in your parallel scenario at all.
While putting together an alternative patch I discovered a bug in addDefaultExcludes. The array length may be wrong if default exlcudes are modified while this method executes. I'll attach my version of the fix here once Ant's test suite is through.
Created attachment 28018 [details] Alternative fix for thread-safety issue of default excludes @Adam: it would be great if you could apply my proposed alterantive and see whether any multithreading problems occur.
> @Adam: That should have been Alex, sorry. Stefan
Hi Stephan, Sorry for the slow response; been very busy. I will give your patch a shot as soon as I get some time to do it. Hopefully sometime in the next couple of weeks. Thanks for the help!
... sorry, I meant to say @Stefan. I guess it's contagious :-D
Applied my version of the patch with svn revision 1234276 Please reopen this bug if the problem persists.