Information Technology Reference
In-Depth Information
Statically prior to executing, where moni-
tored components are selected and the ap-
plication is then run. The application must
be stopped and restarted if the selected set
of components changes.
certain events occur. Whenever a CORBA client
calls a server component client stub and server
skeleton interceptors are invoked. Each intercep-
tor can perform any arbitrary function, such as
timestamping an event or recording information
about a call to a log file.
OVATION provides a number of predefined
probes, including:
Dynamically while the application is run-
ning, where the monitored components can
be selected at runtime. Dynamic selection
helps developers focus on problem area and
analyze it without incurring overhead due
to measurement of other components.
Snooper Probe, which captures CORBA
operation information, such as request name,
arguments, request start time, end time and
the threads and the processes to which an
operation belongs;
Li (2002) has implemented both approaches
and suggests that static selection is more straight-
forward (in terms of instrumentation effort) than
dynamic selection. Dynamic selection is more
complicated because it must avoid data incon-
sistency that can arise if a component process
receives an off event, where monitoring is forced
to stop during a run. Modifying instrumentation
dynamically thus relies on the system reaching
a steady state.
The current MCBS prototype is restricted
to synchronous remote procedure calls. It does
not support dynamic function invocations (e.g.,
through CORBA DII) nor does it support stub-
less colocated objects.
Milestone Probe, which permits the manual
demarcation of specific events in the applica-
tion code; and
Trace Probe, which is used to capture
information about the other non-CORBA,
C++ or Java object method calls.
OVATION also allows users to add their own
custom probes to the monitoring framework. This
feature allows develop ers to profile application-
specific characteristic without changing their
source code. Moreover, custom probes can be
dynamically enabled and disabled at run time.
Call graphs among components, along with
latency measurements, are reconstructed for each
scenario. OVATION generates log files during
program execution that contain information detail-
ing processes, threads, and objects involved in the
interaction. The OVATION visualizer transforms
the log file into a graphi cal representation of the
recorded remote object interactions. An example
screenshot from the visualizer showing measured
call sequences is illustrated in Figure 9.
OVATION
OVATION (Object Computing Incorporated,
2006; Gontla, Drury, & Stanley, 2003) is a dis-
tributed monitoring framework that uses similar
concepts as the MCBS framework. It is, however,
specifically targeted to CORBA middleware and
has been tested on both TAO (Schmidt, Natara-
jan, Gokhale, Wang, & Gill, 2002) and JacORB
(Brose, 1997).
The OVATION tool uses CORBA Portable
Interceptors (OMG, 2002) to insert probes. Por-
table Interceptors are based on the Interceptor
pattern (Schmidt et al., 2000), which allows
transparent addition of services to a framework
and automatic triggering of these services when
Summary of operating System and
Middleware Profiling Techniques
All applications interact with the operating sys-
tem and many interact with middleware services
for distributed communication, fault tolerance,
Search WWH ::




Custom Search