| Summary: | JVMTI Profiler blocks JVM Initialization in "enabled" mode if the Agent Controller is not running | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Asaf Yaffe <asaf.yaffe> | ||||||
| Component: | TPTP | Assignee: | Alexander N. Alexeev <analexee> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P1 | CC: | analexee, ewchan, guru.nagarajan, igor.alelekov, jgwest, jkubasta, viacheslav.g.rybalov, vitaly.a.provodin | ||||||
| Version: | unspecified | Keywords: | plan | ||||||
| Target Milestone: | --- | Flags: | asaf.yaffe:
review+
igor.alelekov: review+ |
||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | closed460 | ||||||||
| Attachments: |
|
||||||||
|
Description
Asaf Yaffe
The call to registerAgent() in ACCollector::Init() is blocking. registerAgent() waits for the Agent Controller to start and does not return until registration is successful. You are right that the PIAgent behavior is the correct one to follow, however doing some messages to the console doesn't sound consistent or correct. Plus that string would need translation if not already done. Pls resolve this in i4 AC framework should provide not-blocking function similar to existing registerAgent() function. Description of the function says: // registerAgent() establishes a private connection with the Agent Controller // and creates a thread to get messages coming in from that connection. Does not // return until the AC's agentRegistered response is received. // // 1) Creates a named pipe which this agent will use to receive commands // coming from the Agent Controller process. This pipe cannot be used to send // commands to the Agent Controller because the AC will never read from this pipe, // only write to it. // 2) Starts a thread which runs the handleMessages() function, that listens on that // pipe for commands coming to the agent from the AC. // 3) Sends a CONNECT command request to the AC which will result in a CONNECTION_COMPLETE // response being received on the handleMessages thread. // 4) Sends a registerAgent command to the AC which will result in a agentRegistered response // being received on the handleMessages thread. // // returns 0 if successful The function two times sends commands to AC and waits for responses (by semaphores). It is easy to implement new function that starts new thread and delegates commands sending to this thread. This may be the same thread that handles messages or other one. AC framework has all required functionality on hand. *** Bug 145832 has been marked as a duplicate of this bug. *** Cannot be contained in 4.4. Note sent to Platform Lead 5/29. Joanna, Given the resources/schedule this cannot be a candidate for 4.4.0.1 Created attachment 87259 [details]
patch
Dedicated thread used for agent registration.
Function asyncRegisterAgent added to BaseAgentImpl for it
Asaf, could you review the patch? Alex, The (simple) change to ACCollector.cpp looks good. Please ask Igor Alelekov to review the Agent Controller code changes (I have problems building the AC code in my environment). If you can attach updated Windows IA-32 AC binaries, I can test the patch to verify that it works. Igor, could you review AC changes. Created attachment 87629 [details]
patched AC binary
Asaf, binary attached
The patch looks good. Patch committed to HEAD Resolving as fixed 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. 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. |