This vote has been open for a week now so I'm going to call it PASSED with 19 +1s and no other votes.
Votes from the following, binding ones marked with a *: Carmine Cristallo Konstantin Bobrovsky *Ant Elder *Geir Magnusson Jr. *Niclas Hedhman Niklas Gustavsson *Matthias Wessendorf Christian Glatschke *Craig L Russell Tim Ellison *Alan D. Cabrera Steve Poole Sonal Goyal Stuart Monteith Edward J. Yoon *Roland Weber *Robert Burrell Donkin *Niall Pemberton Richard Cole Congratulations Kato and best wishes for the Incubation. ...ant On Thu, Oct 30, 2008 at 9:14 AM, ant elder <[EMAIL PROTECTED]> wrote: > The Kato proposal has been out for discussion for a few weeks now, > please vote on accepting the Kato project for incubation. > > The full Kato proposal is available at the end of this message and as > a wiki page at http://wiki.apache.org/incubator/KatoProposal. > > Here is my +1 > > ...ant > > = Kato - Post-mortem JVM Diagnostics API and RI/TCK for JSR 326 = > > Abstract > > Kato is a project to develop the Specification, Reference > Implementation and Technology Compatibility Kit for JSR 326: > Post-mortem JVM Diagnostics API > Proposal > > JSR 326 is intended to be a Java API specification for standardising > how and what can be retrieved from the contents of post-mortem > artefacts -- typically process and JVM dumps. Project Kato is intended > to be the place where the Specification, Reference implementation (RI) > and Technology Compatibility Kit (TCK) are openly created. The > intention is that the Specification and RI will be developed in tight > unison, guided by a user-story-focused approach to ensure that > real-world problems drive the project from the beginning. > > Unusually for new APIs, this project will endeavour to encompass the > old and the new. A diagnostic solution that only works when users move > to the latest release does little to improve diagnosability in the > short term. This project will consume existing dump artefacts as well > as possible while developing an API that can address the emerging > trends in JVM and application directions. The most obvious of these > trends are the exploitation of very large heaps, alternative languages > and, paradoxically for Java, the increased use of native memory > through vehicles such as NIO. > Background > > Post-mortem versus Live Monitoring: It's worth noting that the term > "post mortem" is used loosely. It does not just imply dead JVMs and > applications; JSR 326 also covers living, breathing applications where > the dump artefacts are deliberately produced as part of live > monitoring activity. Live monitoring generally means tracing, > profiling, debugging, or even bytecode monitoring and diagnosis by > agents via the java.lang.instrument API . It can also mean analysis of > dumps to look for trends and gather statistics. The live-monitoring > diagnostic space is well served except for this last area, which is > where JSR 326 can help. > > IBM developed an API called DTFJ ("Diagnostic Tooling and Framework > for Java") as a means of providing its support teams a basis on which > to write tools to diagnose Java SDK and Java application faults. It > consists of a native JVM-specific component and the DTFJ API, which > was written in pure Java. > Rationale > > JSR 326 exists because of the widely acknowledged limitations in > diagnosing Java application problems after the fact. There are many > good ways to understand and diagnose problems while they happen, but > few credible or pervasive tools exist for helping resolve problems > when all has gone suddenly and horribly wrong. Outside of "live > monitoring" there is no standard way to provide diagnostics > information, and hence no standard tools. Each tool writer has to > figure out how to access the data individually and specifically for > each JVM vendor and operating system. This sparsity of tools has meant > that users have limited options in diagnosing their own problems, > especially unexpected or intermittent failures. Consequently these > users turn to the providers of their software to work out what is > happening. Application, middleware, and JVM vendors are spending > increasing time supporting customers in problem diagnosis. Emerging > trends indicate that this is going to get worse. > > Today JVM heap sizes are measured in small numbers of gigabytes, > processors on desktops come in twos or fours, and most applications > running on a JVM are written in Java. To help analyse problems in > these configurations, we use a disparate set of diagnostic tools and > artefacts. If the problem can't be reproduced in a debugger, then > things quickly get complicated. There are point tools for problems > like deadlock analysis or the ubiquitous Java out-of-memory problems, > but overall the Java diagnostic tools arena is fragmented and JVM- or > OS-specific. Tool writers have to choose their place in this matrix. > We want to change that by removing the need for tool writers to make a > choice. By enabling tool writers to easily target all the major JVM > vendors and operating systems, we expect the number and capability of > diagnostic tools to greatly increase. Tomorrow it gets harder; heap > sizes hit 100's of gigabytes, processors come packaged in powers of > 16, and the JVM commonly executes a wide range of language > environments. We can't tackle tomorrow's problems until we have a > platform to address today's. > > This project is about bringing together people and ideas to create > that platform, and we can't think of a better place to do that than in > Apache. > Initial Goals > > The code donated by IBM will not be a complete solution as the > JVM-specific portion will be missing. The initial goals will be to > close this gap by creating equivalent open-source replacements. We > plan to create code to be able to understand a dump related to the > Apache Harmony Dynamic Runtime Layer Virtual Machine (DRLVM). We also > intend to create an HPROF dump format reader. > > After that the expectation is that we work to produce ways to better > understand the contents of a process dump. This will allow the work on > solving native out-of-memory problems to proceed. > Current Status > Meritocracy > > We appreciate how important it is to create and maintain a healthy > environment based on meritocracy. We will do all we can to ensure that > all opportunities to contribute are visible and that contributions are > rewarded appropriately. > Community > > In developing a standard it's tempting to get into an small group, > write a specification, and then present it to the world. We do not > want to do that. We strongly believe that any software interface > standard should be developed in as visible a way as possible and show > that it has taken the views of the industry into account. We see that > the best way to do that for JSR 326 is to develop the specification > and implementation in unison, in the open. The JSR expert group is > intended to represent the industry, while the RI and example tools > will demonstrate the specification's usefulness and applicability. The > specification will be developed by incrementally proposing problem > statements, constructing specification changes, implementing them > within the RI, and demonstrating practicability with example tools. > The JSR specification mailing list will be open to everyone to see and > contribute to. > > The technology that is outlined by this proposal serves to bring > standardisation to a fragmented area. We hope and expect that > developing this technology will attract the right folks and that a > community of data providers and data consumers will develop around it. > We are already building relationships with existing tool writers, with > the intention of understanding what they need and showing, by their > adoption of this API, that we've got it right. > Known Risks > Orphaned Products > > The development of, and continuing support for, this project is > important to a number of companies. There is no risk of this code > being suddenly abandoned. > Inexperience with Open Source > > There is a mixed level of experience with Open Source. > Homogeneous Developers > > The initial list of committers consists of developers from IBM and one > independent. The committers are based in Europe. There is a general > level of experience in working in a distributed way. There will be > more more developers from other companies joining but they have not > yet officially confirmed their participation. > Reliance on Salaried Developers > > Most of the developers are paid by their employer to contribute to > this project. However the subject matter of this project holds a > fascination for many people and over time we expect to see more > volunteers contributing. > Relationships with Other Apache Products > > Currently the initial seed code uses the Ant build tool only. The need > for a suitable open-source JVM from which to harvest dumps, and to > explore ways to understand them, requires that this project forge good > links with the Apache Harmony project. Since this project is about > standardising content and access methods, opportunities also exist to > explore closer links with search technologies such as Lucene. There is > also potential for the semantics of other Apache projects that use > Java, such as Struts or Felix, to be exposed using Kato. For example, > a module could be written that describes loaded classes in terms of > OSGi bundles instead of just class loaders. It is also possible that > the Apache Harmony project may want an implementation of Kato. > > Generally we see this project as helping other Apache projects simply > because we are improving the diagnostic capabilities of Java. We will > welcome all types of diagnostic problem statement and dumps from other > Apache projects. > An Excessive Fascination with the Apache Brand > > Kato is about creating an API and a community of data providers and > data consumers. Creating this API requires that both groups work > together as openly as possible. > > In fact, Kato lives or dies by the strength of its community. We > believe that there is mutual benefit to the project and to the Apache > brand if this work is carried out as an Apache project. The project > gains by being seen to be serious in its objectives of maintaining a > fair, inclusive and equitable approach. Apache benefits from the > acceptance of a project that we hope will push technical boundaries > and grow to be a community of reasonable size. > Documentation > > Information about JSR 326 is available at > > [WWW] http://jcp.org/en/jsr/detail?id=326 > > Information on IBM's DTFJ can be found at > > [WWW] > http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.60/html/dtfj.html > Initial Source > > IBM will donate its Diagnostic Tool Framework for Java (DTFJ) > technology as a seed for development. This codebase consists of > diagnostic dump readers and the data access API. There are data > providers for DTFJ that are specific and proprietary to IBM JVMs; > these providers will not be open-sourced. DTFJ is being donated to > kick start the project and as a foundation on which to build and > develop our ideas. There is no expectation that the final output must > resemble this seed offering. > Source and Intellectual Property Submission Plan > > Apache would receive all source and documentation under the Apache > Corporate Contributor agreement. IBM is the only license holder. > External Dependencies > > Ant and JUnit are the only external dependencies. > Cryptography > Required Resources > Mailing Lists > > * > > kato-private > * > > kato-dev > * > > kato-spec > > Subversion Directory > > * > > [WWW] https://svn.apache.org/repos/asf/incubator/kato > > Issue Tracking > > * > > JIRA : Kato (KATO) > > Other Resources > Initial Committers > > Steve Poole spoole at uk dot ibm dot com > > Stuart Monteith monteith at uk dot ibm dot com > > Carmine Cristello cristallo at uk dot ibm dot com > > Richard Cole rich dot cole at uk dot ibm dot com > > Christian Glatschke christian at glatschke dot com > > Sonal Goyal sonalgoyal4 at gmail dot com > Affiliations > > The initial committers listed are affiliated with IBM and self. > Champion > > Geir Magnusson Jr has agreed to be Champion > Proposed Apache Sponsor > > Incubator PMC > > Nominated Mentors > Geir has volunteered to be a mentor. > Ant Elder >
