Community
Participate
Working Groups
Users of the RAC/agent communication layer have complained that there is no tracing support to help with debugging communication problems between the RAC and agent. This tracing support should be added so that it can be turned on at run time, for example via an environment variable. Tracing will likely have to be done to a file. Tracing should be added to RABindings.c and the File pointer could be stored in ra_agenthandle_t. Contact Dave Smith.
not contained in 4.0, moving to 4.1 as P1
This is targeted for new agent controller.
Here are some clarification on this request with Dave Smith: - this tries to aid the debugging on the agent side (mainly named pipe but shared memory would be a nice addition). - because the AC will support multiple instances on the same system, the environment variable may not work well. The suggestion is to make it configurable in the AC configuration file: AGENT_COMM_TRACE = YES/NO AGENT_COMM_TRACE_FILE = trace.log In the future, if we need dynamic configuration, this could be converted in to an AC command at run time. The single log will contain traces for all agents (with proper agent id tags) - The main communication activities that are need to be logged are in "RABindings.c" and "hcbnd.c" Here is the summary of the effort: - impact to the configuration reading and setting - named pipe and shared memory operations will be traced Sizing: - two weeks to write up the design, review and approve by the community (especially what type of and how much info should be traced, and the format of the trace records, probably using CBE) . The design will appy for any transport layer (e.g. socket is included) - one week of coding and testing
I expanded the scope to cover tracing for client, agent controller, and base agent layers. Changed the title to reflect the expanded scope.
See this URL for latest sizing and design issues: http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_79564.html
*** Bug 97159 has been marked as a duplicate of this bug. ***
This feature should also provide a configurable logging facility for Agent Controller and agents. For increased serviceability of the new Agent Controller code and all C/++ and Java agents written for the new Agent Controller, provide a configurable logging facility with the following capabilities (analogous to JSR-047 or Java Logging): -Level filtering for different uses (e.g. loggers). -Configurable sinks (e.g. handlers) for different uses (e.g. loggers) that can be configured based on logging level. -File and Logging Agent sinks (e.g. handlers). -Configuration for file sinks (e.g. handlers) to limit the total amount of storage resource consumed by the log file files (e.g. rollover). -Common Base Event support.
Changing to P1 as per the 4.1 official plan.
Reassigned to Andy.
From defect #80013: The new org.eclipse.hyades.logging.native native Common Base Event implementation should be used to reinstrument the existing log message in the Data Collection Engine for increased PD capabilities (e.g. viewing, filtering, sorting, analysis, correlation). This includes: -Port the existing instrumented log messages (e.g. ra_logServiceMessage()) to log native Common Base Events including a situation and source component ID. -Instrument new log messages for all types of situations: -Start -Stop -Connect -Configure -Request -Feature -Dependency -Create -Destroy -Report -Available -Other See fix for defect https://bugs.eclipse.org/bugs/show_bug.cgi?id=79657 for an illustrative example of Common Base Event logging in C/++.
The basic logging support is in place for the Agent Controller and agents. I still need to look into the code and make sure the logging service is actually being called at the appropriate places. A few other loose ends need to be tied up, such as logging from shared libraries, client logging, and filtering based on a configured log level.
The logging framework has been put in place for the new Agent Controller. I have opened new bugzilla reports to capture the remaining effort to round this out more fully. These new items are: 111943, 111946 and 111947
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.
