Community
Participate
Working Groups
Profiling Perspective does not load trace data captured from a Logging Agent. Using the enclosed DemoLoggingAgent.java class (see instructions with attachment), the valid trace data send via a Logging Agent and loaded into the TPTP Trace model is not loaded into the various trace data views of the Profiling Perspective. For example, opening the Memory Statistics view renders a blank table despite valid data being in the model and refreshing the view.
Created attachment 49501 [details] DemoLoggingAgent.java Instructions: 1) Add the following methods to the org.eclipse.hyades.logging.core.LoggingAgent.java class (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=140242): public String getAgentUUID(){ return delegate.getAgentUUID(); } public long getPID(){ return delegate.getPID(); } 2) Run DemoLoggingAgent.java. 3) Attach to 'Demo Logging Agent' Logging Agent.
The view may be associated with Profiling type agent only and Logging agent is filtered to display trace data.
This appears to be a model loading problem after further investigation. Using the enclosed trace XML data (derived from profiling a Java application to a file), the context (e.g. node/process/agent) and core events (e.g. class definitions and object allocations) are loaded, but the method invocations are not (see the enclosed serialized models). As such, moving to the model component and assigning to Ruth. Please increase the priority to P1 since this blocks #119688.
Based on a discussion with Paul, sounds like only part of the data is being loaded into the model. Reassigning to Platform.Model and upgrading to P1 because this is blocking Paul's Tech Preview, Java API Recorder.
Created attachment 49962 [details] ResourceContents_LoggingAgent.xmi
Created attachment 49963 [details] ResourceContents_Profiling.xmi
Created attachment 49964 [details] DemoLoggingAgent.java
what's the ETA on this fix?
A work-around has been found for the API Recorder (163170) - manually setting the necessary configuration options on the target agent. As such, this defect is not required by the API Recorder in 4.3 i3. As such, lowering the severity. However, this defect is still valid since emitting Trace XML data via a Logging Agent and loading the trace events in the Trace EMFD model is a standard use case for TPTP and our users/consumers.
Defer these defects to 4.4 because they can't be contained by end of day today and they're not on any critical list.
Lower priority to P2 in the list of 4.4
Paul, can you provide a trcxml file with the events, or a standalone agent file fo events to reproduce this problem without having to run the sample agent etc.? It iwll seed my debugging/fixing
Created attachment 86211 [details] Trace XML file.
(In reply to comment #12) > Paul, can you provide a trcxml file with the events, or a standalone agent file > fo events to reproduce this problem without having to run the sample agent > etc.? > > It iwll seed my debugging/fixing > Attached. However, this import scenario seems to work. The concern is with the attach scenario not loading the trace data, event with the agent type set to Profiler (this should not be required as well).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
Reopening since still relevant.
Reopening since still relevant. Can we triage this into TPTP 4.6.2/4.6.3.
Paul, how pervasive is this problem for the user?
(In reply to comment #19) > Paul, how pervasive is this problem for the user? Not very. It does creep into the API Recorder use case but we have worked around it there. Although emitting Trace XML data via a Logging Agent and loading the trace events in the Trace EMF model is still a valid use case, I am fine with closing it for now.
Based on the resource on the team and the fact that the problem is not very pervasive, I'm resolving this defect as Won't Fix.
Closing.
