Derby
  1. Derby
  2. DERBY-900

Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6
    • Fix Version/s: 10.1.3.1, 10.2.1.6
    • Component/s: Network Client
    • Labels:
      None
    • Issue & fix info:
      Patch Available

      Description

      These constructors use the Java default platform encoding to convert the bytes to a String, this typically leads to bugs on platforms with different encodings.

      Replace with code using fixed conversion, or alternative mechanisms.
      If the call is required its use should be commented as to why it is required.

      org.apache.derby.client.am.ClobOutputStream - some existing bug?
      org.apache.derby.client.am.DateTime - see DERBY-877
      org.apache.derby.client.am.sqlca

      I generated this list using the Java search in eclipse for references to the constructors
      String(byte[])
      String(byte[],int,int)

      1. derby900.diff.p1.txt
        2 kB
        Sunitha Kambhampati
      2. derby900.stat.p1.txt
        0.2 kB
        Sunitha Kambhampati
      3. TestEnc.java
        7 kB
        Sunitha Kambhampati
      4. for_10.1_derby900.diff.p1.txt
        1 kB
        Sunitha Kambhampati
      5. for_10.1_derby900.stat.p1.txt
        0.1 kB
        Sunitha Kambhampati
      6. derby900.test.diff.txt
        4 kB
        Sunitha Kambhampati
      7. derby900.test.stat.txt
        0.2 kB
        Sunitha Kambhampati
      8. Derby900.p2.diff.txt
        8 kB
        Sunitha Kambhampati
      9. derby900.p2.stat.txt
        0.2 kB
        Sunitha Kambhampati
      10. derby900.p2_encodingChange.diff.txt
        4 kB
        Sunitha Kambhampati
      11. derby900_p2_cleanup.diff.txt
        8 kB
        Sunitha Kambhampati
      12. derby900_p2_cleanup.stat.txt
        0.2 kB
        Sunitha Kambhampati
      13. testsecmec.zip
        64 kB
        Kathey Marsden

        Activity

        Hide
        Deepa Remesh added a comment -

        org.apache.derby.client.am.ClobOutputStream - DERBY-683 is open for this

        Show
        Deepa Remesh added a comment - org.apache.derby.client.am.ClobOutputStream - DERBY-683 is open for this
        Hide
        Sunitha Kambhampati added a comment -

        This patch (derby900.diff.p1.txt and derby900.stat.p1.txt ) is for the trunk, and focuses on fixing the usage of default string constructors in the client that can cause encoding problems.

        I searched in Eclipse for the String(byte[]) and String(byte[],int,int) constructors and in the current codeline there is one such method in sqlca.java#bytes2String which is used in about 7 places.

        Please note, there are some more encoding issues as Kathey points out in http://issues.apache.org/jira/browse/DERBY-877#action_12364297
        http://issues.apache.org/jira/browse/DERBY-951

        I discussed with Kathey on IRC yesterday.
        – String.getBytes() is used in a number of places (DateTime,NetConnectionReply) which will need to be fixed.
        – Server always sends UTF8 encoding for the SQLCARD strings, hence the bytes2String method needs to correctly use UTF8 encoding to decode the strings.

        This fix
        – use UTF8 encoding in bytes2String.

        Tests:
        I have used the repro for DERBY-583 (Thanks Kathey) that uses lang/ConcurrentImplicitCreateSchema.java that shows the problem. I have also added this test to run as part of the encodingTests in trunk.

        To repro on windows,
        java -Dframework=DerbyNetClient -DderbyTesting.encoding=UTF-16 org.apache.derbyTesting.functionTests.harness.RunTest lang/ConcurrentImplicitCreateSchema.java

        Results:
        without this fix, the exception sqlstate is all garbled up.
        with this fix, the test should pass without any diff.

        Ran derbyall with the patch on linux/ibm142 with no new failures ( insane jars)

        I am continuing to look at the other encoding issues. Please review/commit this patch if it looks good. Thanks.

        Show
        Sunitha Kambhampati added a comment - This patch (derby900.diff.p1.txt and derby900.stat.p1.txt ) is for the trunk, and focuses on fixing the usage of default string constructors in the client that can cause encoding problems. I searched in Eclipse for the String(byte[]) and String(byte[],int,int) constructors and in the current codeline there is one such method in sqlca.java#bytes2String which is used in about 7 places. Please note, there are some more encoding issues as Kathey points out in http://issues.apache.org/jira/browse/DERBY-877#action_12364297 http://issues.apache.org/jira/browse/DERBY-951 I discussed with Kathey on IRC yesterday. – String.getBytes() is used in a number of places (DateTime,NetConnectionReply) which will need to be fixed. – Server always sends UTF8 encoding for the SQLCARD strings, hence the bytes2String method needs to correctly use UTF8 encoding to decode the strings. This fix – use UTF8 encoding in bytes2String. Tests: I have used the repro for DERBY-583 (Thanks Kathey) that uses lang/ConcurrentImplicitCreateSchema.java that shows the problem. I have also added this test to run as part of the encodingTests in trunk. To repro on windows, java -Dframework=DerbyNetClient -DderbyTesting.encoding=UTF-16 org.apache.derbyTesting.functionTests.harness.RunTest lang/ConcurrentImplicitCreateSchema.java Results: without this fix, the exception sqlstate is all garbled up. with this fix, the test should pass without any diff. Ran derbyall with the patch on linux/ibm142 with no new failures ( insane jars) I am continuing to look at the other encoding issues. Please review/commit this patch if it looks good. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        I am attaching the patch for 10.1 codeline- ' for_10.1_derby900.diff.p1.txt' and 'for_10.1_derby900.stat.p1.txt.'

        The code changes are the same as in the derby900.diff.p1.txt.
        Thus, the fix
        – uses UTF8 encoding in bytes2String.

        But for the 10.1 codeline since derbyTesting.encoding property is not there, I am attaching a standalone repro 'TestEnc.java' for testing.

        OUTPUT for 10.1
        $ java -cp "C:/workghm/svnclient/ks10.1/classes;." -Dfile.encoding=UTF-16 -Dconsole.encoding=Cp1252 TestEnc
        Initializing connection type: derbynetclient
        driver: org.apache.derby.jdbc.ClientDriver
        url: jdbc:derby://localhost:1527/wombatderbynetclient;create=true;traceFile=derbynetclient.trace
        Obtaining the connection
        Database: Apache Derby 10.1.2.4
        T E S T P A S S E D
        g o t S Q L S t a t e 4 2 Y 0 7
        e = S c h e m a ' T E S T S C H E M A 1 ' d o e s n o t e x i s t

        ----------------------
        Ran derbynetclientmats with patch on linux/ibm142. Apart from the known failures, the test lang/ConcurrentImplicitCreateSchema failed with the timeout exception (Note - this test was fixed for the timeout issue on trunk). This failure is not related to this patch.

        Can someone please review/commit this patch. Thanks.

        Show
        Sunitha Kambhampati added a comment - I am attaching the patch for 10.1 codeline- ' for_10.1_derby900.diff.p1.txt' and 'for_10.1_derby900.stat.p1.txt.' The code changes are the same as in the derby900.diff.p1.txt. Thus, the fix – uses UTF8 encoding in bytes2String. But for the 10.1 codeline since derbyTesting.encoding property is not there, I am attaching a standalone repro 'TestEnc.java' for testing. OUTPUT for 10.1 $ java -cp "C:/workghm/svnclient/ks10.1/classes;." -Dfile.encoding=UTF-16 -Dconsole.encoding=Cp1252 TestEnc Initializing connection type: derbynetclient driver: org.apache.derby.jdbc.ClientDriver url: jdbc:derby://localhost:1527/wombatderbynetclient;create=true;traceFile=derbynetclient.trace Obtaining the connection Database: Apache Derby 10.1.2.4 T E S T P A S S E D g o t S Q L S t a t e 4 2 Y 0 7 e = S c h e m a ' T E S T S C H E M A 1 ' d o e s n o t e x i s t ---------------------- Ran derbynetclientmats with patch on linux/ibm142. Apart from the known failures, the test lang/ConcurrentImplicitCreateSchema failed with the timeout exception (Note - this test was fixed for the timeout issue on trunk). This failure is not related to this patch. Can someone please review/commit this patch. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        I am attaching a patch 'derby900.test.diff.txt, derby900.test.stat.txt' that affects only tests.

        Changes are
        – remove the ConcurrentImplicitCreateSchema from the encodingTests suite. We dont run the ConcurrentImplicitCreateSchema test on trunk(10.2) because it has a high rate of failure on different platforms.
        – add a new test (TestEnc) that repros the derby-583 and the issues that are fixed as a result of DERBY-900 and DERBY-901 and DERBY-902

        I ran the encodingTests suite with jdk15 and tests passed OK.

        Can someone please review and commit this patch. Thanks.

        Show
        Sunitha Kambhampati added a comment - I am attaching a patch 'derby900.test.diff.txt, derby900.test.stat.txt' that affects only tests. Changes are – remove the ConcurrentImplicitCreateSchema from the encodingTests suite. We dont run the ConcurrentImplicitCreateSchema test on trunk(10.2) because it has a high rate of failure on different platforms. – add a new test (TestEnc) that repros the derby-583 and the issues that are fixed as a result of DERBY-900 and DERBY-901 and DERBY-902 I ran the encodingTests suite with jdk15 and tests passed OK. Can someone please review and commit this patch. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        one pending patch for review/commit - derby900.test.diff.txt. Thanks.

        Show
        Sunitha Kambhampati added a comment - one pending patch for review/commit - derby900.test.diff.txt. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        With the changes checked in for DERBY-1127, now, there are 3 places where non portable String.getBytes() is used in client which is in NetConnectionReply.parseSQLDCGRP

        This patch(Derby900.p2.diff.txt) removes use of this non portable method from the client and does some cleanup as part of removing usage of the String.getBytes() method.

        Explanation of changes :
        – Server sends SQLSTATE in UTF8 encoding.

        – see below code snippet ( taken from parseSQLDCGRP )
        int sqldcCode = readFastInt(); // SQLCODE
        **********
        String sqldcState = readFastString(5, netAgent_.targetTypdef_.getCcsidSbcEncoding()); // SQLSTATE
        ***********
        int sqldcReason = readFastInt(); // REASON_CODE
        int sqldcLinen = readFastInt(); // LINE_NUMBER
        int sqldcRown = (int) readFastLong(); // ROW_NUMBER

        // save +20237 in the 0th entry of the rowsetSqlca's.
        // this info is going to be used when a subsequent fetch prior is issued, and if already
        // received a +20237 then we've gone beyond the first row and there is no need to
        // flow another fetch to the server.
        if (sqldcCode == 20237) {
        rowsetSqlca[0] = new NetSqlca(netAgent_.netConnection_,
        sqldcCode,
        sqldcState.getBytes(), //************
        null,
        netAgent_.targetTypdef_.getCcsidSbc());

        Basically the sqldcState is read using UTF8 or netAgent_.targetTypdef_.getCcsidSbcEncoding() and converted to a String and
        then converted back to bytes using the bad non portable getBytes(). In NetSqlca, the sqldcState bytes and ccsid is passed in. The sqlstate bytes is set to sqldcState_ in NetSqlca and it is decoded using UTF8 in getSQLState using the method Sqlca::bytes2String.

        In short, the getBytes() should take UTF-8 encoding but it seems much cleaner to do the cleanup here to avoid doing the extra conversion. currently conversion happens from bytes to string, and then to bytes and then back to string.

        Cleanup includes:
        --The ccsid in NetSqlca is never used and I have cleaned that up.
        --NetSqlca takes in sqlstate as bytes and then is converted to string. Instead since we have a string available already, there is no need of an extra conversion as seen in code snippet above. I have changed the NetSqlca constructor to take in
        the sqlstate as String.
        – There is one place where the sqlstate is retrieved as bytes and passed to the NetSqlca constructor as such. I have overloaded the NetSqlca constructor to take in the sqlstate bytes and convert it to a string in the constructor itself.
        – cleaned up Sqlca.getSQLState()

        – During the cleanup one thing odd was all or most of the method signatures in this codepath have a throws DisconnectException even though some of them do not have any code that would throw this exception. In any case I have not cleaned those instances as I think it might be better to address them separately from this patch/issue.
        – The NetSqlca constructor that does the conversion of the sqlstate bytes to string will throw a unsupportedencodingException that is thrown as a SqlException. This SqlException is wrapped into a DisconnectException in parseSQLCAGRP. I followed the same approach as Reply.readFastString() that wraps the UnsupportedEncodingException into a DisconnectException.

        I think lots more encoding related cleanup can be done in client, but I will leave that for DERBY-951.

        This is a client only change and I ran derbynetclientmats on windows/jdk142 ok. I also ran derbynetclientmats and derbynetmats on Z/OS with no new failures.
        I also ran the encodingTests with sun jdk1.5 OK.

        Can someone please look at this change. Thanks.

        Show
        Sunitha Kambhampati added a comment - With the changes checked in for DERBY-1127 , now, there are 3 places where non portable String.getBytes() is used in client which is in NetConnectionReply.parseSQLDCGRP This patch(Derby900.p2.diff.txt) removes use of this non portable method from the client and does some cleanup as part of removing usage of the String.getBytes() method. Explanation of changes : – Server sends SQLSTATE in UTF8 encoding. – see below code snippet ( taken from parseSQLDCGRP ) int sqldcCode = readFastInt(); // SQLCODE ********** String sqldcState = readFastString(5, netAgent_.targetTypdef_.getCcsidSbcEncoding()); // SQLSTATE *********** int sqldcReason = readFastInt(); // REASON_CODE int sqldcLinen = readFastInt(); // LINE_NUMBER int sqldcRown = (int) readFastLong(); // ROW_NUMBER // save +20237 in the 0th entry of the rowsetSqlca's. // this info is going to be used when a subsequent fetch prior is issued, and if already // received a +20237 then we've gone beyond the first row and there is no need to // flow another fetch to the server. if (sqldcCode == 20237) { rowsetSqlca [0] = new NetSqlca(netAgent_.netConnection_, sqldcCode, sqldcState.getBytes(), //************ null, netAgent_.targetTypdef_.getCcsidSbc()); Basically the sqldcState is read using UTF8 or netAgent_.targetTypdef_.getCcsidSbcEncoding() and converted to a String and then converted back to bytes using the bad non portable getBytes(). In NetSqlca, the sqldcState bytes and ccsid is passed in. The sqlstate bytes is set to sqldcState_ in NetSqlca and it is decoded using UTF8 in getSQLState using the method Sqlca::bytes2String. In short, the getBytes() should take UTF-8 encoding but it seems much cleaner to do the cleanup here to avoid doing the extra conversion. currently conversion happens from bytes to string, and then to bytes and then back to string. Cleanup includes: --The ccsid in NetSqlca is never used and I have cleaned that up. --NetSqlca takes in sqlstate as bytes and then is converted to string. Instead since we have a string available already, there is no need of an extra conversion as seen in code snippet above. I have changed the NetSqlca constructor to take in the sqlstate as String. – There is one place where the sqlstate is retrieved as bytes and passed to the NetSqlca constructor as such. I have overloaded the NetSqlca constructor to take in the sqlstate bytes and convert it to a string in the constructor itself. – cleaned up Sqlca.getSQLState() – During the cleanup one thing odd was all or most of the method signatures in this codepath have a throws DisconnectException even though some of them do not have any code that would throw this exception. In any case I have not cleaned those instances as I think it might be better to address them separately from this patch/issue. – The NetSqlca constructor that does the conversion of the sqlstate bytes to string will throw a unsupportedencodingException that is thrown as a SqlException. This SqlException is wrapped into a DisconnectException in parseSQLCAGRP. I followed the same approach as Reply.readFastString() that wraps the UnsupportedEncodingException into a DisconnectException. I think lots more encoding related cleanup can be done in client, but I will leave that for DERBY-951 . This is a client only change and I ran derbynetclientmats on windows/jdk142 ok. I also ran derbynetclientmats and derbynetmats on Z/OS with no new failures. I also ran the encodingTests with sun jdk1.5 OK. Can someone please look at this change. Thanks.
        Hide
        Kathey Marsden added a comment -

        I am trying to understand the type of case that would cover the code changed and trigger the encoding problem. Do you have any idea what that case might be?

        Kathey

        Show
        Kathey Marsden added a comment - I am trying to understand the type of case that would cover the code changed and trigger the encoding problem. Do you have any idea what that case might be? Kathey
        Hide
        Sunitha Kambhampati added a comment -

        I dont have a testcase available to repro for the p2 patch changes. Let me look more to see if I can get one. Thanks.

        Show
        Sunitha Kambhampati added a comment - I dont have a testcase available to repro for the p2 patch changes. Let me look more to see if I can get one. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        The non portable String.getBytes() is used in parseSQLDCGRP as explained earlier. This method is called by parseSQLDCROW which is called by parseSQLDIAGCI.

        Client flow is as follows:
        parseSQLDIAGCI -> parseSQLDCROW ->parseSQLDCGRP

        But the server currently does not send SQLDIAGCI. The only method that calls writeSQLDIAGCI is in writeSQLDIAGGRP (which is currently commented out code). writeSQLDIAGGRP is called by writeSQLCAXGRP.

        In DRDARConnThread.writeSQLDIAGGRP we only write null data and the callto writeSQLDIAGCI is commented out.

        I tried to see if I could uncomment this code in writeSQLDIAGGRP so I can get a repro, but then it seems like the other methods like writeSQLDIAGSTT also will need to be implemented correctly. The writeSQLDIAGSTT method just returns a null data for now.

        In short, the encoding changes made in parseSQLDCGRP in client is not currently being used.

        The p2 changes are fairly straightforward if you dont include the cleanup changes.
        In parseSQLDCGRP ,
        sqldcState is read, and then sent across to NetSqlca constructor using getBytes(). The encoding to be used is UTF8 since that is what the server sends.

        String sqldcState = readFastString(5, netAgent_.targetTypdef_.getCcsidSbcEncoding()); // SQLSTATE
        // note netAgent_.targetTypdef_.getCcsidSbcEncoding() is UTF8.

        If you feel comfortable with just change to remove the getBytes() to use UTF8 encoding without the cleanup, then I can submit a patch with just that change.

        If you have any ideas or suggestions to repro this, please let me know. Thanks.

        Show
        Sunitha Kambhampati added a comment - The non portable String.getBytes() is used in parseSQLDCGRP as explained earlier. This method is called by parseSQLDCROW which is called by parseSQLDIAGCI. Client flow is as follows: parseSQLDIAGCI -> parseSQLDCROW ->parseSQLDCGRP But the server currently does not send SQLDIAGCI. The only method that calls writeSQLDIAGCI is in writeSQLDIAGGRP (which is currently commented out code). writeSQLDIAGGRP is called by writeSQLCAXGRP. In DRDARConnThread.writeSQLDIAGGRP we only write null data and the callto writeSQLDIAGCI is commented out. I tried to see if I could uncomment this code in writeSQLDIAGGRP so I can get a repro, but then it seems like the other methods like writeSQLDIAGSTT also will need to be implemented correctly. The writeSQLDIAGSTT method just returns a null data for now. In short, the encoding changes made in parseSQLDCGRP in client is not currently being used. The p2 changes are fairly straightforward if you dont include the cleanup changes. In parseSQLDCGRP , sqldcState is read, and then sent across to NetSqlca constructor using getBytes(). The encoding to be used is UTF8 since that is what the server sends. String sqldcState = readFastString(5, netAgent_.targetTypdef_.getCcsidSbcEncoding()); // SQLSTATE // note netAgent_.targetTypdef_.getCcsidSbcEncoding() is UTF8. If you feel comfortable with just change to remove the getBytes() to use UTF8 encoding without the cleanup, then I can submit a patch with just that change. If you have any ideas or suggestions to repro this, please let me know. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        I am dividing the Derby900.p2.diff.txt into two separate patches after talking to kathey.

        This patch derby900.p2_encodingChange.diff.txt makes the encoding related change to remove the non portable String.getBytes() method.

        – use correct encoding UTF8 for sqlstate in NetConnectionReply.::parseSQLDCGRP(Sqlca[] rowsetSqlca, int lastRow)

        Note: this code does not get exercised anywhere as explained in previous comment. Also code coverage results shows that this method is not called anywhere in our tests.

        svn stat
        M java\client\org\apache\derby\client\net\NetConnectionReply.java

        derbynetclientmats ran ok on linux/ibm142.

        The change itself is pretty simple. The diff for this patch shows more lines as changed because of the indentation change as a result of adding a try block.

        Can someone please look at this patch. Thanks.

        Show
        Sunitha Kambhampati added a comment - I am dividing the Derby900.p2.diff.txt into two separate patches after talking to kathey. This patch derby900.p2_encodingChange.diff.txt makes the encoding related change to remove the non portable String.getBytes() method. – use correct encoding UTF8 for sqlstate in NetConnectionReply.::parseSQLDCGRP(Sqlca[] rowsetSqlca, int lastRow) Note: this code does not get exercised anywhere as explained in previous comment. Also code coverage results shows that this method is not called anywhere in our tests. svn stat M java\client\org\apache\derby\client\net\NetConnectionReply.java derbynetclientmats ran ok on linux/ibm142. The change itself is pretty simple. The diff for this patch shows more lines as changed because of the indentation change as a result of adding a try block. Can someone please look at this patch. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        Thanks Kathey for committing my earlier p2 encoding change patch.

        It was decided earlier to break up the derby900.p2.diff.txt, so I am attaching now a patch with the cleanup changes separately in derby900_p2_cleanup.diff.txt. Changes are:

        – remove unnecessary conversion from sqlstate string to bytes and back to string , in parseSQLDCGRP(Sqlca[] rowsetSqlca, int lastRow) in NetConnectionReply.
        This has been done by adding a constructor in NetSqlca to take in the sqlstate as string.
        – cleanup method getSqlState() in Sqlca.
        – cleanup of ccsid_ in Sqlca as it is not used.

        Please note, the parseSQLDCGRP method in the diff shows more changes because of change in indentation because of removal of the try block.

        – ran derbynetclientmats on ibm142/linux OK.

        Can someone please look at this. Thanks.

        Show
        Sunitha Kambhampati added a comment - Thanks Kathey for committing my earlier p2 encoding change patch. It was decided earlier to break up the derby900.p2.diff.txt, so I am attaching now a patch with the cleanup changes separately in derby900_p2_cleanup.diff.txt. Changes are: – remove unnecessary conversion from sqlstate string to bytes and back to string , in parseSQLDCGRP(Sqlca[] rowsetSqlca, int lastRow) in NetConnectionReply. This has been done by adding a constructor in NetSqlca to take in the sqlstate as string. – cleanup method getSqlState() in Sqlca. – cleanup of ccsid_ in Sqlca as it is not used. Please note, the parseSQLDCGRP method in the diff shows more changes because of change in indentation because of removal of the try block. – ran derbynetclientmats on ibm142/linux OK. Can someone please look at this. Thanks.
        Hide
        Kathey Marsden added a comment -

        I applied the patch derby900_p2_cleanup.diff.txt
        I had to merge some files after applying and then ran derbynetclientmats.
        The test derbynet/testSecMec failed with client and on rerun.
        I ran with

        java version "1.4.2_07"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05)
        Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)

        The tail end of the test seems to be cut off. Attached is the test output.

        Show
        Kathey Marsden added a comment - I applied the patch derby900_p2_cleanup.diff.txt I had to merge some files after applying and then ran derbynetclientmats. The test derbynet/testSecMec failed with client and on rerun. I ran with java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) The tail end of the test seems to be cut off. Attached is the test output.
        Hide
        Sunitha Kambhampati added a comment -

        Hi Kathey,

        I synced up till about yesterday as svn is down now and applied the p2 cleanup patch and ran the testSecMec.java with sun 1.4.2_07 and it works OK on my win2000 laptop. I ran this test a couple of times and it passes OK. The tmp file in testsecmec.zip seems to look like as though the test exited in between - this behavior seems to me like the one seen in DERBY-1114. The jvm bug described in DERBY-1114 is fixed in 1.5 and 1.4.2_08 atleast from the entries in the java bug database. However, I didnt see windows platforms being mentioned anywhere in the java bug report.

        can you please try running the test without the patch and see if it passes or not. and if the test passes with antoher jvm -jdk1.5.

        Thanks.

        Show
        Sunitha Kambhampati added a comment - Hi Kathey, I synced up till about yesterday as svn is down now and applied the p2 cleanup patch and ran the testSecMec.java with sun 1.4.2_07 and it works OK on my win2000 laptop. I ran this test a couple of times and it passes OK. The tmp file in testsecmec.zip seems to look like as though the test exited in between - this behavior seems to me like the one seen in DERBY-1114 . The jvm bug described in DERBY-1114 is fixed in 1.5 and 1.4.2_08 atleast from the entries in the java bug database. However, I didnt see windows platforms being mentioned anywhere in the java bug report. can you please try running the test without the patch and see if it passes or not. and if the test passes with antoher jvm -jdk1.5. Thanks.
        Hide
        Sunitha Kambhampati added a comment -

        Thanks Kathey for committing the p2 cleanup patch on trunk..

        Also adding notes here about the testSecMec failure that Kathey mentioned in the previous comment. It seems like that was related to her machine environment and probably a manifestation of same issue mentioned in DERBY-1114. Kathey mentioned that the test failed without the patch on different jvms too.
        ---------------------------------

        I would like the derby900.p2_encodingChange.diff.txt to be ported to 10.1. It is a clean merge. The merge command is

        svn merge -r 398943:398944 https://svn.apache.org/repos/asf/db/derby/code/trunk/

        I merged and then ran derbynetclientmats on ibm142/linux ok.

        Can someone please commit this. Thanks.

        Show
        Sunitha Kambhampati added a comment - Thanks Kathey for committing the p2 cleanup patch on trunk.. Also adding notes here about the testSecMec failure that Kathey mentioned in the previous comment. It seems like that was related to her machine environment and probably a manifestation of same issue mentioned in DERBY-1114 . Kathey mentioned that the test failed without the patch on different jvms too. --------------------------------- I would like the derby900.p2_encodingChange.diff.txt to be ported to 10.1. It is a clean merge. The merge command is svn merge -r 398943:398944 https://svn.apache.org/repos/asf/db/derby/code/trunk/ I merged and then ran derbynetclientmats on ibm142/linux ok. Can someone please commit this. Thanks.
        Hide
        Andrew McIntyre added a comment -

        Committed to 10.1 branch with revision 407473.

        Show
        Andrew McIntyre added a comment - Committed to 10.1 branch with revision 407473.
        Hide
        Andrew McIntyre added a comment -

        Sunitha, please close this issue as resolved if there is no further work to be done.

        Show
        Andrew McIntyre added a comment - Sunitha, please close this issue as resolved if there is no further work to be done.
        Hide
        Daniel John Debrunner added a comment -

        Confirmed no use of these non-portable constructors in the network client code.

        Should remain assigned to Sunitha, but she is not present in the drop down list and it seems no way to leave the assign to field as-is.

        Show
        Daniel John Debrunner added a comment - Confirmed no use of these non-portable constructors in the network client code. Should remain assigned to Sunitha, but she is not present in the drop down list and it seems no way to leave the assign to field as-is.

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development