From looking at the source it seems that the WebSockets.sendBinary methods that take ByteBuffer will take ownership of the buffer, meaning I shouldn't modify (or return it to a pool) after I pass it to these methods. Is this correct?

Looking at sendInternal, the buffer passed is then wrapped in a dummy ImmediatePooledByteBuffer. I could make alternative versions of these sendBinary methods that take PooledByteBuffer. Allowing me to use pooled buffers.

Since this functionality is missing it makes me think that there may be a reason why it shouldn't be done.

_______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

Thanks for the reply Stuart, I've made the modifications I mentioned to the WebSockets class in my project by creating a copy of it and it's working great. I'm wondering if it would be possible to have the PooledByteBuffer versions added into official undertow source. Here's a gist of how it looks like: https://gist.github.com/anonymous/cbb6004adb1a30d4274622814a69284c if it makes sense I can make a fork and pull request, also add PooledByteBuffer versions for all the send methods. On Thu, Jan 26, 2017 at 8:36 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: > > On Fri, Jan 27, 2017 at 6:50 AM, Mario Carbajal > <mario.e.carbajal(a)gmail.com&gt; wrote: > > From looking at the source it seems that the WebSockets.sendBinary > > methods > > that take ByteBuffer will take ownership of the buffer, meaning I > > shouldn't > > modify (or return it to a pool) after I pass it to these methods. Is > > this > > correct? > > Yes, you need to wait for the callback to be called before you can do > anything with it. > > > > > Looking at sendInternal, the buffer passed is then wrapped in a dummy > > ImmediatePooledByteBuffer. I could make alternative versions of these > > sendBinary methods that take PooledByteBuffer. Allowing me to use pooled > > buffers. > > Sounds good. > > > > > Since this functionality is missing it makes me think that there may be > > a > > reason why it shouldn't be done. > > Mostly because nobody has asked for it yet. > > Stuart > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev