hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Veentjer" <alarmnum...@gmail.com>
Subject Re: Feature Designs and Test Plans
Date Thu, 20 Nov 2008 06:47:56 GMT
What about thread safety?

I see that the code base is very large and it is quite hard to analyse
because there is not much documentation if classes are used by
multiple threads/single thread/immutable
Other things I see are:
- eating up interrupted exceptions
- very coarse grained locking
- locking on objects you don't own and nested locking (both deadlock prone)
- using non threadsafe collections in combination with custom locking
(doesn't need to be a bad thing, but not by default)
- java memory model problems (and they are hard to analyse because of
the lack of documentation)

These are a few of the things I have found so far.

I think these things can be simplified by adding them to the guidelines.

On Thu, Nov 20, 2008 at 7:23 AM, Nigel Daley <ndaley@yahoo-inc.com> wrote:
> Hadoop Committers,
> The Hadoop project has grown to become a critical platform for many
> companies.  As we approach a 1.0 release (perhaps within the next 6 months)
> I think it is time we adopt some more rigor around designing and testing new
> features.
> As committers, we are already given a couple duties that relate to quality.
>  From http://wiki.apache.org/hadoop/HowToCommit :
>> If a committer reviews a patch they've not authored, and believe it to be
>> of sufficient quality, then they can commit the patch, otherwise the patch
>> should be cancelled with a clear explanation for why it was rejected.
>> ...
>> Patches should be rejected which do not adhere to the guidelines in
>> http://wiki.apache.org/hadoop/HowToContribute and to the
>> http://wiki.apache.org/hadoop/CodeReviewChecklist. Committers should always
>> be polite to contributors and try to instruct and encourage them to
>> contribute better patches.
> These have been a good starting point, but I'd like to propose more rigor.
> I propose that before we commit issues marked as "New Feature", they must
> have:
>  1. a design doc attachment
>  2. a test plan attachment
> (Templates to be provided for both)
> I believe these 2 items will enhance the communication, design, and quality
> of our new features.
> Are committers open to adopting these further guidelines?
> Thanks,
> Nige

View raw message