Re: Diagnostic Utility For AG
Would also like to see some options given to the user, for the level of details being sent and the ability to review the information before sending it. For example, separate options for - - including the console/geronimo.log - including the config.xml - including the list-modules output - including a file listing of everything under GHOME - including a listing of any GSHell extensions - basic system/environment data (system OS, JVM vendor/version, installed memory/swap, JVM heap, ...) - if the server was running under Eclipse - You'd need a Terms of Use policy describing how the collected data will be used and stored. Also, a option to only make the details available to committers (and not on a public website) would help ease some people's fear. If someone selected that option, we could still include the basic stack trace (for Geronimo or other open source provided code) and the resolution info on the public web, as long as no user unique data was included. -Donald Jason Warner wrote: I think with something like this, at the very least you'd want the standard debug output (stack trace and whatnot). Maybe you could also provide non-personal environment information, though I'm not sure how people would feel about that. If possible, a revision number would be nice, as well as a timestamp if that hasn't been provided in any of the previous information. I like the idea, but I think it's usefulness will be dependent on how well it is implemented. Good luck! On Feb 18, 2008 1:14 PM, Joseph Leong <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Hi all, I wanted to toss an idea out to the community and get some feedback. A few other members of the community and myself are interested in creating a diagnostic utility for AG. This diagnostic utility would perform something similar to what one would see when an application crashes and a prompter allows the end user to send a report to the developers. However this idea has an open source twist to it - rather than the developers exclusively being able to view the issue or contribute a solution, any user can. When an error or issue occurs in AG it'll generate a sort of unique message key that will be used to automatically generate a wiki type page somewhere. This wiki page will include vital information that will help in debugging the issue. There any user/developer can post solutions or thoughts. In addition, we'd try to aim to create some sort of standardized way to generate these message keys so if another user encounters the same error it will redirect or build upon the existing wiki another user has already opened. Ultimately... the hopes are that this tool can serve as a convenient way for users to get help on their issues and expedite that process by automating a process and presenting it in an organized fashion. I know theres plenty room for ideas and improvements to this.. so please feel to comment anything! To start.. does anyone have a list of what they'd like to see in the error reporting diagnostics? Wishing you all the best, Joseph Leong -- ~Jason Warner smime.p7s Description: S/MIME Cryptographic Signature
Re: Diagnostic Utility For AG
David, I don't think that such a thing should/would be built to necessarily automatically generate the wiki itself, but more of automatically generate a URL based on say, an MD5 hash, that if the user were to go to this URL, would create a wiki page at that time (for example, http://geronimo.apache.org/bugs/ ). Upon visiting this URL, users could put any kind of information they want on this wiki-style page... what they were doing, environment, etc... if they have figured a way to prevent or fix it.. that kind of thing. If the page is already created/someone else has already posted information on this particular crash circumstance, this information would be viewable by all subsequent visitors. I agree with you that it would be preferable to have a human-readable key, but also like you I'm at a loss currently as to how to generate such a thing. Perhaps it could be built so that those inputing information based on this hash could also provide a human readable key to access the same page, so that the same information could be accessed by either http://geronimo.apache.org/bugs/ or http://geronimo.apache.org/bugs/ Bottom line, the best thing for this would be to not have fully automatic communication, but more along the lines of user-opted/ controlled submission. Thanks, Erik B. Craig [EMAIL PROTECTED] On Feb 18, 2008, at 12:53 PM, David Jencks wrote: On Feb 18, 2008, at 10:14 AM, Joseph Leong wrote: Hi all, I wanted to toss an idea out to the community and get some feedback. A few other members of the community and myself are interested in creating a diagnostic utility for AG. This diagnostic utility would perform something similar to what one would see when an application crashes and a prompter allows the end user to send a report to the developers. However this idea has an open source twist to it - rather than the developers exclusively being able to view the issue or contribute a solution, any user can. When an error or issue occurs in AG it'll generate a sort of unique message key that will be used to automatically generate a wiki type page somewhere. This wiki page will include vital information that will help in debugging the issue. There any user/ developer can post solutions or thoughts. In addition, we'd try to aim to create some sort of standardized way to generate these message keys so if another user encounters the same error it will redirect or build upon the existing wiki another user has already opened. Ultimately... the hopes are that this tool can serve as a convenient way for users to get help on their issues and expedite that process by automating a process and presenting it in an organized fashion. I know theres plenty room for ideas and improvements to this.. so please feel to comment anything! I'm not sure I understand your proposal. I think that letting a geronimo installation communicate with anything not specifically configured by the system administrator, in particular communicating with a wiki at apache, is not acceptable. I'd be fine with the geronimo build having a profile that constructs wiki pages for each error if they are not already present in the wiki and having the error message include a key to the wiki page. I think it might be good to have the key be human-readable, but I don't have an idea on how to accomplish that. thanks david jencks To start.. does anyone have a list of what they'd like to see in the error reporting diagnostics? Wishing you all the best, Joseph Leong
Re: Diagnostic Utility For AG
On Feb 18, 2008, at 10:14 AM, Joseph Leong wrote: Hi all, I wanted to toss an idea out to the community and get some feedback. A few other members of the community and myself are interested in creating a diagnostic utility for AG. This diagnostic utility would perform something similar to what one would see when an application crashes and a prompter allows the end user to send a report to the developers. However this idea has an open source twist to it - rather than the developers exclusively being able to view the issue or contribute a solution, any user can. When an error or issue occurs in AG it'll generate a sort of unique message key that will be used to automatically generate a wiki type page somewhere. This wiki page will include vital information that will help in debugging the issue. There any user/ developer can post solutions or thoughts. In addition, we'd try to aim to create some sort of standardized way to generate these message keys so if another user encounters the same error it will redirect or build upon the existing wiki another user has already opened. Ultimately... the hopes are that this tool can serve as a convenient way for users to get help on their issues and expedite that process by automating a process and presenting it in an organized fashion. I know theres plenty room for ideas and improvements to this.. so please feel to comment anything! I'm not sure I understand your proposal. I think that letting a geronimo installation communicate with anything not specifically configured by the system administrator, in particular communicating with a wiki at apache, is not acceptable. I'd be fine with the geronimo build having a profile that constructs wiki pages for each error if they are not already present in the wiki and having the error message include a key to the wiki page. I think it might be good to have the key be human-readable, but I don't have an idea on how to accomplish that. thanks david jencks To start.. does anyone have a list of what they'd like to see in the error reporting diagnostics? Wishing you all the best, Joseph Leong
Re: Diagnostic Utility For AG
On Feb 18, 2008 2:52 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > > > > On Feb 18, 2008 2:46 PM, Viet Nguyen <[EMAIL PROTECTED]> wrote: > > Yo Joe, > > > > This is a really subjective problem that we're trying to tackle. > > There's not any type of barometer that will be able to tell us how > > well the Diagnostic Utility is working until we have significant > > participation from end-users. > > > > I think a good way to implement something like this is to have broad > > categories for different types of issues. There was a mention of using > > an md5 hash to map one person's problem to a wiki page. I do not think > > this is the best solution because it will be too issue-specific. > > > > If we imagine each wiki page as a "bucket" and each problem reported > > as an element which will belong to 1+ buckets, then we can see that > > when we have 1000 buckets each with 1 element, then it will be really > > hard to diagnose anything. However, if we have only 100 buckets > > (meaning broader categories) each with 10 elements, the problem will > > be (hopefully) easier to detect and fix. > > > > Use exception package names to create a reporting structure? That, but also the method calls in the stack trace should be somewhat similar (e.g. similar function calls from the same classes). I think it should be a mixture of things, not just one. > > > > Maybe someone with more data mining experience can help out (because I > > have none), but I think we should break down a reported issue into > > certain keywords, and use those as a search criteria for the wiki. > > > > I think I got off topic...but I like Jason's answer. > > > > Thanks, > > Viet > > > > Also, I think this post is related to the topic here too: > > > http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-to15505337.html#a15505337. > > > > > > -- > ~Jason Warner
Re: Diagnostic Utility For AG
On Feb 18, 2008 2:46 PM, Viet Nguyen <[EMAIL PROTECTED]> wrote: > Yo Joe, > > This is a really subjective problem that we're trying to tackle. > There's not any type of barometer that will be able to tell us how > well the Diagnostic Utility is working until we have significant > participation from end-users. > > I think a good way to implement something like this is to have broad > categories for different types of issues. There was a mention of using > an md5 hash to map one person's problem to a wiki page. I do not think > this is the best solution because it will be too issue-specific. > > If we imagine each wiki page as a "bucket" and each problem reported > as an element which will belong to 1+ buckets, then we can see that > when we have 1000 buckets each with 1 element, then it will be really > hard to diagnose anything. However, if we have only 100 buckets > (meaning broader categories) each with 10 elements, the problem will > be (hopefully) easier to detect and fix. > Use exception package names to create a reporting structure? > > Maybe someone with more data mining experience can help out (because I > have none), but I think we should break down a reported issue into > certain keywords, and use those as a search criteria for the wiki. > > I think I got off topic...but I like Jason's answer. > > Thanks, > Viet > > Also, I think this post is related to the topic here too: > > http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-to15505337.html#a15505337 > . > -- ~Jason Warner
Re: Diagnostic Utility For AG
Yo Joe, This is a really subjective problem that we're trying to tackle. There's not any type of barometer that will be able to tell us how well the Diagnostic Utility is working until we have significant participation from end-users. I think a good way to implement something like this is to have broad categories for different types of issues. There was a mention of using an md5 hash to map one person's problem to a wiki page. I do not think this is the best solution because it will be too issue-specific. If we imagine each wiki page as a "bucket" and each problem reported as an element which will belong to 1+ buckets, then we can see that when we have 1000 buckets each with 1 element, then it will be really hard to diagnose anything. However, if we have only 100 buckets (meaning broader categories) each with 10 elements, the problem will be (hopefully) easier to detect and fix. Maybe someone with more data mining experience can help out (because I have none), but I think we should break down a reported issue into certain keywords, and use those as a search criteria for the wiki. I think I got off topic...but I like Jason's answer. Thanks, Viet Also, I think this post is related to the topic here too: http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-to15505337.html#a15505337.
Re: Diagnostic Utility For AG
I think with something like this, at the very least you'd want the standard debug output (stack trace and whatnot). Maybe you could also provide non-personal environment information, though I'm not sure how people would feel about that. If possible, a revision number would be nice, as well as a timestamp if that hasn't been provided in any of the previous information. I like the idea, but I think it's usefulness will be dependent on how well it is implemented. Good luck! On Feb 18, 2008 1:14 PM, Joseph Leong <[EMAIL PROTECTED]> wrote: > Hi all, > > I wanted to toss an idea out to the community and get some feedback. A > few other members of the community and myself are interested in creating a > diagnostic utility for AG. This diagnostic utility would perform something > similar to what one would see when an application crashes and a prompter > allows the end user to send a report to the developers. However this idea > has an open source twist to it - rather than the developers exclusively > being able to view the issue or contribute a solution, any user can. When > an error or issue occurs in AG it'll generate a sort of unique message key > that will be used to automatically generate a wiki type page somewhere. > This wiki page will include vital information that will help in debugging > the issue. There any user/developer can post solutions or thoughts. In > addition, we'd try to aim to create some sort of standardized way to > generate these message keys so if another user encounters the same error it > will redirect or build upon the existing wiki another user has already > opened. Ultimately... the hopes are that this tool can serve as a > convenient way for users to get help on their issues and expedite that > process by automating a process and presenting it in an organized fashion. > > I know theres plenty room for ideas and improvements to this.. so please > feel to comment anything! > > To start.. does anyone have a list of what they'd like to see in the error > reporting diagnostics? > > Wishing you all the best, > Joseph Leong > -- ~Jason Warner
Diagnostic Utility For AG
Hi all, I wanted to toss an idea out to the community and get some feedback. A few other members of the community and myself are interested in creating a diagnostic utility for AG. This diagnostic utility would perform something similar to what one would see when an application crashes and a prompter allows the end user to send a report to the developers. However this idea has an open source twist to it - rather than the developers exclusively being able to view the issue or contribute a solution, any user can. When an error or issue occurs in AG it'll generate a sort of unique message key that will be used to automatically generate a wiki type page somewhere. This wiki page will include vital information that will help in debugging the issue. There any user/developer can post solutions or thoughts. In addition, we'd try to aim to create some sort of standardized way to generate these message keys so if another user encounters the same error it will redirect or build upon the existing wiki another user has already opened. Ultimately... the hopes are that this tool can serve as a convenient way for users to get help on their issues and expedite that process by automating a process and presenting it in an organized fashion. I know theres plenty room for ideas and improvements to this.. so please feel to comment anything! To start.. does anyone have a list of what they'd like to see in the error reporting diagnostics? Wishing you all the best, Joseph Leong
