db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4746) (Server) Implement UTF8 support on DRDA
Date Mon, 20 Sep 2010 14:42:33 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912480#action_12912480

Knut Anders Hatlen commented on DERBY-4746:

The new logic in the patch looks correct to me, but the writeRDBNAM() method is a bit too
aggressive on allocating byte arrays:

+        int len = currentManager.getByteLength(rdbnam);

The UTF-8 CCSID manager will allocate a new byte array in order to find the length, and then
throw it away.

+        /* Initialize the buffer at MAX_NAME - max length in bytes for RDBNAM */
+        ByteBuffer buff = ByteBuffer.allocate(CodePoint.MAX_NAME);

This will allocate a byte buffer with length 255, but after DERBY-4805 it'll increase to ~64K,
and then it's probably going to hurt.

+        /* Convert the RDBNAM into bytes using the current CCSID */
+        currentManager.convertFromJavaString(rdbnam, buff);

Here, the UTF-8 CCSID manager will allocate a new byte array again, holding the contents of
the string, before it puts it into the ByteBuffer.

+        /* Get the byte array out of the byte buffer */
+        int bytesLen = buff.position();
+        byte[] rdbBytes = new byte[bytesLen];

And here yet another byte array is allocated before it's sent to DDMWriter.

I think if writeRDBNAM() had used writeScalarPaddedString() instead of writeScalarPaddedBytes(),
we could avoid some of these byte array allocations. We wouldn't avoid all of them, because
writeScalarPaddedString() would still call getByteLength() and convertFromJavaString() internally,
but at least 2 and 4 would go away.

As a possible future improvement, we may also consider changing Utf8CcsidManager's implementation
of convertFromJavaString(String,ByteBuffer) and getByteLength() so that they don't create
any byte arrays internally.

> (Server) Implement UTF8 support on DRDA
> ---------------------------------------
>                 Key: DERBY-4746
>                 URL: https://issues.apache.org/jira/browse/DERBY-4746
>             Project: Derby
>          Issue Type: Sub-task
>    Affects Versions:
>            Reporter: Tiago R. Espinha
>            Assignee: Tiago R. Espinha
>             Fix For:
>         Attachments: DERBY-4746.diff, DERBY-4746.diff, DERBY-4746.diff, DERBY-4746_p2-impl.diff,
DERBY-4746_p2-impl.diff, DERBY-4746_p2-tests.diff, DERBY-4746_p2-tests.diff, DERBY-4746_p3.diff,
DERBY-4746_p3.diff, DERBY-4746_p3.diff, TestClient.java
> I'm branching out this issue into server and client changes. Since the changes are incremental
and small, DERBY-728 would soon become confusing if it had to bear the patches for both server
and client.
> For future reference, some patches have actually been applied in DERBY-728. These **ARE**
also required for the server implementation.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message