Anoop Sam John commented on HBASE-20078:

Yes Ram.  We have test for getShort also where one byte is one BB and next one 
in the next BB.  

> MultiByteBuff : bug in reading primitives when individual buffers are too 
> small
> -------------------------------------------------------------------------------
>                 Key: HBASE-20078
>                 URL: https://issues.apache.org/jira/browse/HBASE-20078
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: stack
>            Assignee: Anoop Sam John
>            Priority: Major
>             Fix For: 2.0.0, 3.0.0
>         Attachments: HBASE-20078.patch
> Copied from the bottom of HBASE-13916, the JIRA that introduced MultiByteBuff:
> [~anoop.hbase] This bit of code needs more test. It does not seem to be doing 
> the right thing....
> Doing something like the below, it does not seem to be returning the right 
> answers....
> {code}
>   @Ignore // This test fails.
>   @Test
>   public void testGetInt() {
>     ByteBuffer bb1 = ByteBuffer.allocate(1);
>     bb1.put((byte)1);
>     ByteBuffer bb2 = ByteBuffer.allocate(1);
>     bb2.put((byte)0);
>     ByteBuffer bb3 = ByteBuffer.allocate(1);
>     bb3.put((byte)0);
>     ByteBuffer bb4 = ByteBuffer.allocate(1);
>     bb4.put((byte)1);
>     MultiByteBuff mbb = new MultiByteBuff(bb1, bb2, bb3, bb4);
>     // Value is wrong here ... needs adjusting but code is doing wrong thing.
>     assertEquals(256, mbb.getIntAfterPosition(0));
>   }
> {code}
> Ignore the expected answer in the above... just a place holder as i messed 
> with the return... but if I make buffers of one byte, we do not seem to be 
> moving into the next buffer properly... If I make the buffers of two bytes, 
> similar. This stuff normally works because we are not spanning buffer 
> boundaries... but if we do, response seems like it could be off sir. I'll 
> have a go at this. You might have input meantime.
> The issue is the individual BBs are too small. Ideally that would never 
> happen. Still better to solve this corner cases.

This message was sent by Atlassian JIRA

Reply via email to