[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [tptp-monitoring-tools-dev] Re:request approval for 156880


+1


Thank you,
Valentina Popescu
Senior Advisory Analyst
IBM Toronto Labs
Phone:  (905)413-2412         (tie-line  969)
Fax: (905) 413-4850



"Doddapaneni, Srinivas P" <srinivas.p.doddapaneni@xxxxxxxxx>
Sent by: tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx

09/16/2006 01:59 PM

Please respond to
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>

To
"TPTP Monitoring Tools Project developer discussions" <tptp-monitoring-tools-dev@xxxxxxxxxxx>
cc
<tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx>
Subject
RE: [tptp-monitoring-tools-dev] Re:request approval for 156880





+1
 
Thanks,
-Sri



From: tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx [mailto:tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Nan
Sent:
Saturday, September 16, 2006 8:25 AM
To:
TPTP Monitoring Tools Project developer discussions
Cc:
TPTP Monitoring Tools Project developer discussions; tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx
Subject:
Re: [tptp-monitoring-tools-dev] Re:request approval for 156880

 

The decision was made based on an agreement with consumers, in fact this was supposed to be a bonus performance gain in 4.2.1 but unfortunately is revealing some  inconsistencies in our own tool which need to be clarified before enabling this feature. I agree there are ways to overcome this problem, we have thought about alternatives, but we believe that we cannot afford to do any more significant code changes at this very late stage of the cycle. I am stressing that it is unfortunate that we have to back it out but it seems to me the best decision. The code changes are really minor and local, and they involve only commenting out some lines of code.  I have reviewed them with Dave twice this week so I think we are safe to go.


Kind regards,


Alexandru Nan - Software Developer
phone:  905-413-6029
e-mail: apnan@xxxxxxxxxx
IBM Lab,
8200 Warden Ave.
Markham, Ontario, Canada
L6G 1C7


Harm Sluiman/Toronto/IBM@IBMCA
Sent by: tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx

09/16/2006 08:53 AM


Please respond to
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>


To
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>
cc
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>, tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx
Subject
Re: [tptp-monitoring-tools-dev] Re:request approval for 156880

 


   






I think there may be other ways to work around this, but unfortunately at this stage I agree backing out the function seems like the right thing to do.

Have the funding consumers been made aware of this? We don't want a panic request to do a 4.2.2.


Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 1-647-300-4758
mailto:sluiman@xxxxxxxxxx
Admin : Arlene Treanor atreanor@xxxxxxxxxx  Tie: 969-2323 1-905-413-2323

Alex Nan/Toronto/IBM@IBMCA
Sent by: tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx

09/15/2006 07:49 PM


Please respond to
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>


To
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>
cc
 
Subject
[tptp-monitoring-tools-dev] Re:request approval for 156880

 


   







I am requesting approval for the defect https://bugs.eclipse.org/bugs/show_bug.cgi?id=156880 which is reporting a regression introduced in 4.2.1  as part of a performance improvement https://bugs.eclipse.org/bugs/show_bug.cgi?id=151704.


The problem is when a CBE XML log file generated in native encoding (for ex. windows-1252) having no header that indicates the file encoding and containing non-ASCII characters the XML parser, that we are using to optimize the performance of the import, will stop parsing at the encounter of the first non UTF-8 character sequence, the imported log will be truncated and no error message displayed. TPTP4.2 and previous releases are using the GLA to read the file and the GLA uses the encoding that the user is providing in the import log wizard, by default the JVM default encoding (native encoding). Although the code in 4.2.1 is more performant we need to back it out because there are cases of CBE XML log files with no header (i.e. containing CBE XML fragments) in other encodings then UTF-8 that the current local CBE XML import cannot handle correctly. We will address the performance improvement in a future release together with a consistent approach regarding CBE XML encodings (i.e. making sure all our tools are producing UTF-8 CBE XMLs but also backward compatibility for importing  non-UTF-8 files would need to be provided) .


1) Explain why you believe this is a stop-ship defect.  How does the defect manifest itself, and how will users of TPTP / consuming products be affected if the defect is not fixed?
I have already explained above why this is a stop ship issue. Downstream products need consistency in behaviour. They need to be able to importlogs containing CBE XML fragments generated with non UTF-8 encodings.

Since this is a regression the fix is required.



2) Is there a work-around?  If so, why do you believe the work-around is insufficient?
The workaround is to import logs using the RAC faking a remote import via (127.0.0.1) or to have the user add the encoding header into the XML document. Since we would have inconsistencies in our approach towards importing CBE XMLs we think that this is not acceptable.

3) Is this a regression or API breakage?  Explain.
This is a regression introduced in 4.2.1.

4) Does this require new API?
No.

5) Who performed the code review?
Alex Nan, Dave Smith.

6) Is there a test case attached to the bugzilla record?
Monitor.UI.ImportLog.testsuite has been updated with the
Import_CBE_XML_NON_UTF8  test case that tests this problem.

7) What is the risk associated with this fix?
Low.

8) Is this fix related to any standards that TPTP adheres to?  If so, who has validated that the fix continues to adhere to the standard?
No.



Alexandru Nan - Software Developer
phone:  905-413-6029
e-mail: apnan@xxxxxxxxxx
IBM Lab,
8200 Warden Ave.
Markham, Ontario, Canada
L6G 1C7
_______________________________________________
tptp-monitoring-tools-dev mailing list
tptp-monitoring-tools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tptp-monitoring-tools-dev
_______________________________________________
tptp-monitoring-tools-dev mailing list
tptp-monitoring-tools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tptp-monitoring-tools-dev
_______________________________________________
tptp-monitoring-tools-dev mailing list
tptp-monitoring-tools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tptp-monitoring-tools-dev