Bugzilla – Full Text Bug Listing
| Summary: | Create shared memory buffer (loggers <-> monitors). | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Paul Slauenwhite <paulslau> |
| Component: | TPTP | Assignee: | jkubasta |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | knight, labadie |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | housecleaned460 closed460 | ||
|
Description
Paul Slauenwhite
This enhancement would require extensive changes to the agent monitoring architecture, to be able to attach and monitor data from an agent associated with a process that has already ended. Currently, the Haydes Data Collection Engine creates the shared memory data channel only when a client attaches and starts monitoring the agent. For this enhancement, a shared memory data channel would need to be created when the agent registers with the Haydes Data Collection Engine. The enhancement would require changes to the Haydes Data Collection Engine process and agent handling code, to persist information about the process and its agents and their data channels, for a period of time after the process exits, if there is data in the data channels. The majority of the changes are to the Haydes Data Collection Engine server and agent code but there may also be changes required to org.eclipse.hyades.execution.local and org.eclipse.hyades.execution.remote. As such, transferring ownership to component owner. Please change this to P1 for version 4.1 today so it can be considered in the 4.1 plan. We require this feature now. I have two questions regarding this feature request. 1. If the application/agent which collected the data has exited, how can any client/tool attach to it and receive the data even if it were in the shared memory buffer. The real requirement seems to me as "Agents can publish data to some entity, likely agent controller, that can be discovered and received by client even after the agent terminates." 2. In the case that agent does not terminate, it can and should buffer the data it collects until a client is ready to receive it. This feature was discussed at the Data Collection and Communication subsystem meeting on 3/31/05. Summarized below are some suggested solutions using features targeted for TPTP 4.1. Any agent that requires buffering and persistence of data beyond its life- time, should consider implmenting a service agent to meet its needs. Agent controller in 4.1 release supports agent-to-agent communication. This provides the minimum support needed in the platform to create a data buffering service. If the agent requires a dedicated communication channel with service agent, it can negotiate that after hand-shake. Please respond if this is a workable solution for you. (In reply to comment #3) > I have two questions regarding this feature request. > 1. If the application/agent which collected the data has exited, how can any > client/tool attach to it and receive the data even if it were in the shared > memory buffer. The real requirement seems to me as "Agents can publish data to > some entity, likely agent controller, that can be discovered and received by > client even after the agent terminates." > 2. In the case that agent does not terminate, it can and should buffer the > data it collects until a client is ready to receive it. 1) Yes, this is the requirement. Maybe I am misunderstanding the current architecture. As I see it, when the Agent Controller launches a Java application that is calling the LoggingAgent Java wrapper, this wrapper currently buffers all logged messages until a client is attached and monitoring. If the Java application terminates or crashes, this buffer is terminated since it resides in the JVM's memory. If the native side of the LoggingAgenet implemented shared memory, the LoggingAgent Java wrapper could pass-though all logged messages and let the native layer handle buffering until a client is attached and monitoring. This way, is the Java application terminates or crashes, the logged messages are still persisted in the native layer for clients to retrieve for serviceability purposes. 2) Yes. Actually, buffering takes place for both scenarios when the Java application is executing and terminated. This would presume some sort of expiration on buffered logged messages. (In reply to comment #4) > This feature was discussed at the Data Collection and Communication subsystem > meeting on 3/31/05. Summarized below are some suggested solutions using > features targeted for TPTP 4.1. > Any agent that requires buffering and persistence of data beyond its life- > time, should consider implmenting a service agent to meet its needs. Agent > controller in 4.1 release supports agent-to-agent communication. This provides > the minimum support needed in the platform to create a data buffering service. > If the agent requires a dedicated communication channel with service agent, it > can negotiate that after hand-shake. > Please respond if this is a workable solution for you. This solution appears to be viable. What is the performance/memory impact of have in effect two agents instead of one? Would the client attach/monitor the service agent? Overall, memory and CPU usage shuold be better considering that it give control to managing buffer sizes to the service agent. Since majority of agents will not need this feature, the agent controller will be able to optimize for this. Of course, there is an additional process and shared memory buffer. I will close this for now. If the suggested solution is not acceptable, reopen it. I am still not complete sure of your proposed solution. Is the client workbench actually attaching to the service agent? Also, does the C impl of the Logging Agent or the Java wrapper implement the service agent. I guess I need some documentation on your solution to determine if it is viable. Deferring from 4.1 as per the official 4.1 enhancement plan. http://eclipse.org/tptp/home/project_info/featureplans/features.php?source=All&project=All&release=4.1&file=TPTPFeatures_4.1.xml To be considered for 4.2 plan Not containable in 4.2, reset target to future. Is there any status update on this feature? This enhancement is: 1) A P1 priority required by consuming products. 2) Has been opened for 2 1/2 years. 3) Required for features schedule for release as a TPTP V4.2.0 Technology Preview. Please ensure that this feature is considered in the planning process for TPTP V4.3.0. Transferring general agent controller enhancement requests to new project lead (Joanna) for consideration in future releases. Mass update of P1 enhancements and defects targetted to future to P2. 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. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). 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. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). 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. |