atom feed9 messages in org.eclipse.tptp-monitoring-tools-devRE: [tptp-monitoring-tools-dev] Re:re...
FromSent OnAttachments
Doddapaneni, Srinivas PSep 1, 2006 10:11 am 
Alex NanSep 15, 2006 4:49 pm 
Harm SluimanSep 16, 2006 5:53 am 
Alex NanSep 16, 2006 8:24 am 
Doddapaneni, Srinivas PSep 16, 2006 10:58 am 
Valentina PopescuSep 16, 2006 12:21 pm 
Nagarajan, GuruSep 16, 2006 6:50 pm 
Dave SmithSep 17, 2006 1:30 pm 
Paul SlauenwhiteSep 17, 2006 4:20 pm 
Subject:RE: [tptp-monitoring-tools-dev] Re:request approval for 156880
From:Valentina Popescu (
Date:Sep 16, 2006 12:21:25 pm


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

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

To TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>

cc TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@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

To TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>


Subject [tptp-monitoring-tools-dev] Re:request approval for 156880  


I am requesting approval for the defect which is reporting a regression introduced in 4.2.1  as part of a performance improvement

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 ( 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?


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