Joe Toomey
Senior Software Engineer
Rational Software
IBM Software Group
Richard Duggan <rduggan@xxxxxxxxxx> Sent by: hyades-dev-admin@xxxxxxxxxxx
05/26/2004 12:13 AM
Please respond to
hyades-dev@xxxxxxxxxxx
To
Hyades-dev@xxxxxxxxxxx
cc
Subject
[hyades-dev] M10 checkin
defects for committer vote
These are the defect fixes we have in hand and intend commit drop late
Wednesday for Thursdays driver.
Defect list. Specifics listed below in the same order
bugzilla_62317
bugzilla_63902
bugzilla_62577
bugzilla_60642
bugzilla_63843
bugzilla_57462
bugzilla_60633
Rational: The generic log adapter may have configuration files deployed
as
many different sub-configurations of the remote data collection packaging.
There needs to be a mechanism by which we can override the relative
directory where these configuration files are located based upon the
sub-configuration which has provided the log file support.
Test Plan: This fix has been tested on all of the supported platforms.
It
has been tested with two different sub-configurations. A full regression
will be ran on the Thursday build.
Risk Assessment: There is an additional field required as part of
the log
file import extension point to specify the sub-configuration that contains
the log files. Without this fix we cannot locate configuration files
provided by extenders of Hyades.
Rational: Dump files generated as part of the optimized heap dump
capabilities in the profiling agent do not provide the workbench the proper
name of the dump files when generated on iSeries. This is because
the file
names on the operating system are EBCIDIC and need to be converted to ASCII
before being sent to the workbench. The code change is isolated to
only
iSeries machines.
Test Plan: This fix has been tested on iSeries. It will be
regression
tested on Thursdays driver.
Risk Assessment: Without this fix we will not be able to retrieve optimized
heap dumps on iSeries. The risk of regression is effectively non-existant
as this is only a iSeries fix and the fix is limited to a simple
system
call to do the conversion.
Rational: The profiling agent may run in 'full' mode, measuring all
memory
and execution behaviour, when it was desired for it to measure nothing.
It
is desirable to completely disable the measurement of the Java application
when extenders have provided data collection capabilities, and wish to
be
able to only collect that extended behaviour and none of the Hyades
provided measurement capabilities.
Test Plan: This has been unit tested and will be regression tested
against
all platforms using the Thursday driver.
Risk Assessment: The opportunity for regression are minimal here.
Rational: When profiling in standalone file no error conditions are
reported to the user. In all other modes error messages are routed
through
to the data collection central log. Severe errors should be reported
to
the user to assist in the diagnosis of problems in standalone mode. This
will be done through stderr.
Test Plan: This has been unit tested and will be regression tested
against
all platforms using the Thursday driver.
Risk Assessment: The opportunity for regression are minimal. There
is the
possibility the user will now be presented with stderr test in the console
which is not generated as part of the application under test. This
will
only occur in severe error conditions and is analogous to many console
programs.
Rational: Managing duplicate Guids across multiple processes can
result in
a tight infinite loop when one process exits prematurely whilst negotiating
its seed. There are a couple of error conditions that can occur
negotiating the seed to ensure uniqueness of guids across processes. We
need to ensure that the state is well defined when we exit our seed
resolution and we also need to ensure that we can recover from other
processes that have corrupted the seed negotiation mechanism due to
untimely exit. This fix provides some additional error handling to
enure
that the state is well defined at the end of the negotiation. It
also
provided a tight spin lock that can force a cleanup of the negotiation
mechanism as part of error recovery.
Test Plan: This has been unit tested and will be regression tested
against
all platforms using the Thursday driver.
Risk Assessment: The algorithm is unusable as is. Without the
fix it is
possible to loop infinitely when other processes have corrupted the
negotiation. The unfortunate side-effect is that the tight spin
can hurt
seeding performance but this should not be the normal behaviour.
Rational: Different environments that are creating Common Base Events
will
have security requirements for managing who can manipulate the static
information or properties that are used to generate Common Base Event
information. Examples are: J2EE environments need to control content
is
restricted to current web applications only, users can override system
properties, etc. We will remove all system property configuration
capabilities to circumvent malicious code from overriding system
properties. As for controlling access to the event factories, we
need to
back out some of the security code we have introduced here as it is to
cumbersome to manage in its current state. We will rely upon runtime
environments to impose their own security model.
Test Plan: This has been unit tested and will be regression tested
against
all platforms using the Thursday driver.
Risk Assessment: There is a behaviour change in the specialization
of the
event factory we have provided as we are removing the system property
capabilities. The code change is straight forward and the opportunity
for
regression is minimal.
Rational: There are issues with certain JVM's having defects in their
JVMPI implementations that cause the JVM to catastrophically fail when
we
exercise the broken code. It is desirable to be able to determine
exactly
what JVM we are running against so we can circumvent the problems before
they result in catastrophic failure.
Test Plan: This has been unit tested against all platforms and will
be
regression tested against all platforms using the Thursday driver.
Risk Assessment: This change requires an addition of a JNI call
into the
JVM_INIT_DONE event of the profiler to query the JVM for its
version/provider details. You need to be careful when calling JNI
from
with JVMPI events as they are not guaranteed to be thread safe in all
conditions (ie. making calls in the wrong events can cause you grief).
At
the time JVM_INIT_DONE is called JNI calls should be completely safe and
we
have confirmed with at least one JVM provider that this will be fine.
Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396
_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev