[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] M10 checkin defects for committer vote

I vote yes for these defects

Antony

----- Original Message -----
From: "Richard Duggan" <rduggan@xxxxxxxxxx>
To: <Hyades-dev@xxxxxxxxxxx>
Sent: Wednesday, May 26, 2004 5:13 AM
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
>
>
> Bugzilla defect 62317: https://bugs.eclipse.org/bugs/show_bug.cgi?id=62317
>
> 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.
>
>
> Bugzilla defect 63902: https://bugs.eclipse.org/bugs/show_bug.cgi?id=63902
>
> 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.
>
>
> Bugzilla defect 62577: https://bugs.eclipse.org/bugs/show_bug.cgi?id=62577
>
> 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.
>
>
> Bugzilla defect 60642: https://bugs.eclipse.org/bugs/show_bug.cgi?id=60642
>
> 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.
>
>
> Bugzilla defect 63843: https://bugs.eclipse.org/bugs/show_bug.cgi?id=63843
>
> 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.
>
> Bugzilla defect 57462: https://bugs.eclipse.org/bugs/show_bug.cgi?id=57462
>
> 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.
>
> Bugzilla defect 60663: https://bugs.eclipse.org/bugs/show_bug.cgi?id=60663
>
> 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
>