Intermittent IndexOutOfBoundsException about asynchbase HOT 13 CLOSED

fix for that. octo47@50b2a18

from asynchbase.

Perfect thanks for the quick response. Do you know when this fix will be merged back into main repository?

from asynchbase.

I tried to repro the bug (see the commit I just attached to this issue, tsuna/asynchbase@c4209af) but I'm not successful so far. Can you help me reproduce it please?

I'm also using netty-3.5.2.Final.jar so I'm not sure why @octo47's change would fix the problem. It's pretty late over here so maybe I'm missing something obvious.

from asynchbase.

netty fails to read from empty ChannleBuffer. I got exact the same exception, and my patch fixed it for me.

from asynchbase.

I believe you @octo47 but I would like to understand the exact circumstances under which this problem is triggered so that we can have a regression test for it. The one I posted above (tsuna/asynchbase@c4209af) doesn't seem to trigger the problem.

from asynchbase.

It is hard to reproduce. This bug triggered only in CompositeChannelBuffer, which in turn can be used by netty only under moderate load or big replies. But it is easy to see the bug in the code.

Suppose, we have keyvalue, which has only key and family. Qualifier and value are empty. With this conditions, after key and family have been read, we will be at line https://github.com/octo47/asynchbase/blob/50b2a18cb602e7973dfd36d8083fe480578172d9/src/KeyValue.java#L259 (patched version). As metioned above, qualifier will has 0 bytes length. Due of described situation, incoming buffer will depleted. Suppose, we don't check length and call buf.readBytes(qualifier); In turn we call method org.jboss.netty.buffer.CompositeChannelBuffer#componentId (via readBytes). In case of depleted buffer, index will be beyond buffer bounds (we already red all data from it), but method componentId checks, that index is not out of bounds, and of couse, it is. And as expected, exception has been thrown.
But your regression tests passed well, because in tests HeapChannelBuffer used, and it has very simple and safe implementation of readBytes
public void getBytes(int index, byte[] dst, int dstIndex, int length) {
System.arraycopy(array, index, dst, dstIndex, length);
}

Thus, you can't reproduce, until you find, how to force netty to use CompositeChannelBuffer.

Hope this helps.

from asynchbase.

As @octo47 has stated, I've had a lot of trouble being able to reproduce this. I have isolated this in our application down to one table, however, I still haven't been able to reliably reproduce this.

Looking at the data in my table however, I don't see any cells with empty qualifiers, however I do have various cells that have empty values.

I will continue on trying to replicate this issue.

from asynchbase.

Artificial reproducible code is not very hard to write.

public class TestIssue40 {
  public static void main(String[] args) {
    final HeapChannelBuffer b1 = new LittleEndianHeapChannelBuffer("ha-ha".getBytes());
    // check, that HCB works:
    b1.getBytes(5, new byte[0], 0, 0);

    final ArrayList<ChannelBuffer> bufs = new ArrayList<ChannelBuffer>();
    bufs.add(b1);
    final CompositeChannelBuffer bbb = new CompositeChannelBuffer(ByteOrder.LITTLE_ENDIAN, bufs, true);
    // but CCB - fails
    bbb.getBytes(5, new byte[0], 0, 0);
  }
}

from asynchbase.

This is a Netty bug, discussed at netty/netty#474, fixed in 3.5.8 – I will make sure to ship with that version (or a newer one) with asynchbase 1.4.0

from asynchbase.

anyway, why we need to touch buffers, if we already know, that no data will be read?

PS: thanks for link to the bug

from asynchbase.

True, I will merge in your fix too.

from asynchbase.

Alright so the actual change I intend to merge in to close this bug is tsuna/asynchbase@73d4639

from asynchbase.

Thanks for the quick resolution guys

from asynchbase.