directory-dev mailing list archives

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

http://issues.apache.org/jira/browse/DIRMINA

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

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

Mime
View raw message