[
https://issues.apache.org/jira/browse/AVRO-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-1227:
-------------------------------
Attachment: AVRO-1227.patch
Thanks for finding this!
Here's a patch that applies after running the command:
svn mv lang/java/avro/src/test/java/org/apache/avro/reflect/ByteBufferTest.java
lang/java/avro/src/test/java/org/apache/avro/reflect/TestByteBuffer.java
This adds a missing call to flushBuffer().
> 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
> 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
