directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner
Date Fri, 13 Jan 2006 12:10:07 GMT
2006/1/13, <>:
> 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

This is a great idea.  Why don't you post this to the JIRA?

We'll really appreciate it because it makes us really easy to track the
changes and known issues.

Thanks in advance,
what we call human nature is actually human habit
PGP Key ID: 0x854B996C

View raw message