You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2018/01/11 14:56:22 UTC

[GitHub] sschepens opened a new pull request #1056: DoubleByteBuf fix for Netty > 4.1.12

sschepens opened a new pull request #1056: DoubleByteBuf fix for Netty > 4.1.12
URL: https://github.com/apache/incubator-pulsar/pull/1056
 
 
   It seems `DoubleByteBuf` is not playing well when used with Native Transports.
   Using @merlimat [test](https://gist.github.com/merlimat/799b8ba84b5987de369668a748aa0e32) I was able to reproduce this.
   Switching from Epoll to Nio transport fixes the issue, so this has to be something with native transports.
   Also, changing [this line](https://github.com/apache/incubator-pulsar/blob/master/pulsar-common/src/main/java/org/apache/pulsar/common/api/DoubleByteBuf.java#L386) to `allocateDirect` fixes the issue for both Epoll and Nio, but I don't know if it's the right thing to do. 
   The most simple fix is not try to allocate a new `ByteBuffer` but return a concatenation of the components' nio buffers.
   
   Therefore, I propose making `DoubleByteBuf.nioBuffers` return a concatenation of the two components' `nioBuffers` when index and length are not needed, this could prove be more efficient. Also make `nioBuffer` allocate a direct buffer if both components are direct, i believe this should be safe also.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services