avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AVRO-1227) Java: Large ByteBuffers may corrupt binary encoding
Date Tue, 22 Jan 2013 22:14:13 GMT

     [ https://issues.apache.org/jira/browse/AVRO-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Doug Cutting updated AVRO-1227:
-------------------------------

    Fix Version/s: 1.7.4
         Assignee: Doug Cutting
           Status: Patch Available  (was: Open)

I'll commit this soon unless there are objections.
                
> Java: Large ByteBuffers may corrupt binary encoding
> ---------------------------------------------------
>
>                 Key: AVRO-1227
>                 URL: https://issues.apache.org/jira/browse/AVRO-1227
>             Project: Avro
>          Issue Type: Bug
>    Affects Versions: 1.7.3
>            Reporter: Scott Carey
>            Assignee: Doug Cutting
>             Fix For: 1.7.4
>
>         Attachments: AVRO-1227.patch
>
>
> From comments in AVRO-1081:
> {quote}
> Hi,
> I'm not sure where to send this so please let me know if I should send it somewhere else!
> Maybe this is just the case in 1.7.3, but it seems that ByteBufferTest is not actually
run by Maven (because it's not named TestByteBuffer, so it doesn't match the test rules),
and I am getting failures on its test() method if I force it to run. Specifically, this is
happening:
> The test's X class has two fields, X.name (a String) and X.content (a ByteBuffer). It
seems they are expected to maintain that order by the reader and writer.
> The writer first writes X.name as a String to its local buffer.
> The writer calls BufferedBinaryEncoder.writeFixed(ByteBuffer) to write X.content. If
the size of the content exceeds 2048 bytes (bulkLimit), writeFixed() bypasses the local buffer
and writes directly to the underlying sink (which was previously empty).
> The X.name String is then flushed to the sink after X.content, thus reversing the order
of the fields.
> The reader fails because it is expecting the fields in the original order (as the schema
and class both specify).
> Also, if the size of X.content is less than 2048 bytes, the contents are in expected
order and the test passes.
> The actual reported error message is:
> Tests in error:
> test(org.apache.avro.reflect.TestByteBuffer): java.io.IOException: Block read partially,
the data may be corrupt
> Anyway, I don't know how important this functionality is, but in any case, it doesn't
appear to be tested in the current Maven setup. Just wanted to let you know!
> Regards,
> Judy Hay
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message