Dear Wiki user, You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.
The "HowToUseConcurrencyAnalysisTools" page has been changed by KonstantinBoudnik. http://wiki.apache.org/hadoop/HowToUseConcurrencyAnalysisTools?action=diff&rev1=1&rev2=2 -------------------------------------------------- * JSure: static analysis of concurrent applications * Flashlight: dynamic concurrency analysis - It happened as a result of Yahoo! Hadoop team engaging with SureLogic to evaluate their products for Hadoop development. HDFS, MapReduce, and ZooKeeper teams were assessing the tools for three day back in October, 2009. Overall, the results were quite promising and produced some [[https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&customfield_12310230=surelogic|findings already]]. + It happened as a result of Yahoo! Hadoop team engaging with !SureLogic to evaluate their products for Hadoop development. HDFS, !MapReduce, and !ZooKeeper teams were assessing the tools for three day back in October, 2009. Overall, the results were quite promising and produced some [[https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&customfield_12310230=surelogic|findings already]]. === Concurrency analysis tools === - * The idea behind JSure is simple yet highly effective: parts of the application source code are getting tagged with a [[http://surelogic.com/promises/apidocs/index.html|special annotations]]. The parts in question identified by SureLogic analyzer as possibly problematic or even buggy. So having these tags (or annotations) in place will help the analyzer skip annotated spots and will only raise the warning about those left untouched. Such an approach might seems to be to troublesome because it literally requires a developer attention to the every bit of concurrent code which has even slight odor. However, it turns out to be a double-fold benefit: first, one pays some close attention and might even rethink particulars of their application's design and/or implementation; second, the annotations works as a form of design document virtually attached to the source code. + * The idea behind !JSure is simple yet highly effective: parts of the application source code are getting tagged with a [[http://surelogic.com/promises/apidocs/index.html|special annotations]]. The parts in question identified by !SureLogic analyzer as possibly problematic or even buggy. So having these tags (or annotations) in place will help the analyzer skip annotated spots and will only raise the warning about those left untouched. Such an approach might seems to be to troublesome because it literally requires a developer attention to the every bit of concurrent code which has even slight odor. However, it turns out to be a double-fold benefit: first, one pays some close attention and might even rethink particulars of their application's design and/or implementation; second, the annotations works as a form of design document virtually attached to the source code. * Flashlight might be executed in conjunction with JSure or separately. It helps to find concurrency issues in the running code. Clearly, if all concurrency problems were to be found by static checks we won't have any concurrency bugs: it simply won't happen, because we would've been using static analyzers early in the game and detect the issues right on the spot. Unfortunately, it's worst than that. And that's why it is very important to know how your multi-threaded application behaves in the runtime. Highly concurrent [[http://hadoop.apache.org/zookeeper/|ZooKeeper]]'s development team found this tool to be quite useful.
