I have had a similar problems implementing broadcast, and I have modified the ByteBuffer of MINA 8.0 making a method of
asReadOnly() that create a java.nio.ByteBuffer from the asReadOnly of the wrapped nio.buffer.
 
The problem is that the readOnly will share the original byte[] or direct array, so I had hacked the mina bytebuffer just a little in this way:
 
In the MINA byteBuffer.asReadOnly() I create a new mina DefaultByteBuffer container and get into that the nio.buffer copy and the reference to the original mina bytebuffer, and a boolean flag that says if the DefaultByteBuffer wrap a readOnly copy or a real writable nio.bytebuffer. I do an aquire() of the original MINA byteBuffer.
So when the MINA ByteBuffer copy is released, the release method just look at the flag and release the original mina bytebuffer.
The MINA bytebuffer copy _must_ be not pooled obviusly.
 
In this way there is no need to make a copy of the data, but only a new nio.bytebuffer that use the same byte[] or direct array, and the original ByteBuffer will be released only when all the copies will be already written to the channel.
 
If you'd like it I can modify the MINA ByteBuffer of the 9.1 in the same way, it shouldn't be hard.
 
by Fed
----- Original Message -----
Sent: Friday, January 13, 2006 1:21 AM
Subject: Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner

Hi Alex,

2006/1/12, Alessandro Torrisi <[EMAIL PROTECTED]>:
I use a buffer size of 2048 bytes...not so much

Can you explain me this better ? Can I do something to improve or it's simply a fact ?

Could you try to turn off the 'pooled' property of the buffers when you broadcast:

buf.setPooled(false);

Please let me know if this helps.  And please make sure you increased
the direct buffer size as we suggested in the FAQ section.

HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C

Reply via email to