Bugzilla – Full Text Bug Listing
| Summary: | Verify that the GLA demo on the external web site works | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega |
| Component: | TPTP.monitoring | Assignee: | Dave Smith <smith> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | jx_china, norbert.ploett, popescu |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | closed460 | ||
|
Description
amehrega
More findings after some drilling into the code: - The "hanging" behaviour is due to the fact that I had the "Continuous Operation" setting for the context instance set. This does not make sense for importing a static log file. So maybe this should be unchecked for the demo. - The amount of messages can be reduced when I set the Pause Interval for the context instance to a higher value. After these changes the import ends with an error message box "IWAT0027E Error importing the specified log file(s)." Copy-pasting the details yields: =========snip========== IWAT0027E Error importing the specified log file(s). IWAT0412E Errors occurred parsing the log file d:\Temp\sample.log. IWAT0398I Sensor will read file sample.log from directory d:\Temp using the converter command null. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 5 items. IWAT0425I Component OS File Sensor is returning 1 items. IWAT0425I Component OS File Sensor is returning 0 items. IWAT0425I Component OS File Sensor is returning 0 items. IWAT0425I Component OS File Sensor is returning 0 items. =========snip========== The log view is opened but says that it has no filter, and that 0 of 0 records matched the filter. I'll try to find out about the parsing errors now. Even more drilling: In the component definition for the OS File Sensor the logging level is set to 0. --> Even the most minor information message is logged to the adapter's internal log. ParserWrapper.parse() will throw it's LogParserException because it only sees that the message count is >0, without distinction what kind of message was processed. I can increase the logging level (to > 10) to suppress the info messages and there is no more error popup dialog now. So the logging level should be > 10 for the demo to fix the problem. But more needs to be done since I am still not happy because the log view which is opened does not contain any entries, as described before. I looked into all components with the debugger and they all had 36 messages processed, so where does the output go? The question "Where does my output go"? led me to the solution. It can also be found in the documentation (at least partially): Help book Monitoring and analyzing ... --> Determining problems ...--> Creating a log parser --> Creating a rules-based adapter --> Configuring the outputter component says: "4. ... Update the Name, Description and Executable Class for the Outputter. Refer to the Configuration file structure reference to obtain the correct name of outputter classes to use. In the example below, the outputter has been changed to use the LogImportOutputter which receives Common Base Event instances and writes the externalized records to the Log Import loader of the Log and Trace Analyzer." In the demo the outputter type is preset to LoggingAgentOutputter, and consequently the output goes nowhere and nothing is shown in the Log View. BTW when I follow the link to the Configuration file structure then the LogImportOutputter is not listed there so the list does not seem to be up-to- date. The LogImportOutputter can of course be found with the java search, but that is not the way it is supposed to be. OK, so now I have answered all my own questions, maybe others can learn something from it. (I sure learned a lot) I hope that it was not all my fault by making some blunder, but I think somebody should look through the demo example and documentations. Norbert, thank you for your investigation into the problems. We will use this information to improve the GLA demo and documentation. Deferring to 4.1 i3. Cannot contain this work in 4.1. Deferring this to 4.2. This can be fixed later in iteration 4 as it is web documentation This cannot be contained in 4.2. It will be targetted to 4.3 Will try to get this demo fixed once 4.3 is wrapped up. Added sizing. Targetting to complete in i2. Deferring to iteration 3. GLA Demo viewlet has been updated. Here is a link to it: http://www.eclipse.org/tptp/home/documents/tutorials/gla/GLA_Intro/GLA_Intro.viewlet/GLA_Intro_viewlet_swf.html. Thanks to Cindy for making the updates. I committed the updated files to CVS. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |