Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "TPTP non JavaSandbox"
(→Layers of the environment) |
|||
| Line 14: | Line 14: | ||
===correlation across threads, process, processors, machines, business processes?=== | ===correlation across threads, process, processors, machines, business processes?=== | ||
[[TPTP_correlation|More detailed discussion]] | [[TPTP_correlation|More detailed discussion]] | ||
| + | === Presentations === | ||
| + | [[Image:ExtendedIDE_C_Linux_20090112.zip|Extending IDE for C/C++]] (created by Dominique Toupin) | ||
===other things=== | ===other things=== | ||
well be creative and add something here ;-). Actually above here. | well be creative and add something here ;-). Actually above here. | ||
Revision as of 13:20, 27 January 2009
Contents
Overview
There are several broad topics that have come up during discussion of how and if TPTP can or should support languages and environments beyond Java. This page is intended to be a root for several of these threads. Hopefully this will evolve into some concrete proposals for incubator work for the future of TPTP.
Layers of the environment
We see the stack that helps define the architectural boundaries of TPTP as being divided first on the monitored side as being how and what and collector or instrumentation must do to collect and potentially cache data locally, and then what it must communicate out, either in a push or pull style. In TPTP we provide an agent infrastructure to assist with moving data out of the collector and into a process that can communicate with a client. It is not required, but we use a shared memory pipe to do the initial communications and then a socket to talk to the client. By default the collector pushes the data as desired on to the pipe and it is directed as needed to the client unchanged. So we end up with a specification for this format and protocol. Today we have an XML format that has been in use since day 1 and a binary format for a subset of events starting in the 4.5 release.
The next specification layer we have is an EMF based in memory model that is used to receive the data at the client and surface to the actual client for processing. Today we serialize using the EMF XMI serializer but this is not intended to hold our volumes of data and is a place for improvement, which means there is a potential layer that is the optimal storage format. Our UI client is query based against the EMF model we use, and we are in a transition to fully decouple the "view model" from the loader model used as the data arrives. This will allow for faster storage and better isolation for query. The originnal impl. demonstrated many of the initial concepts but is not a scalable solution.
Trace versus logging data
sequential tracing versus aggregated data
correlation across threads, process, processors, machines, business processes?
Presentations
File:ExtendedIDE C Linux 20090112.zip (created by Dominique Toupin)
other things
well be creative and add something here ;-). Actually above here.
Return to the TPTP wiki Page