directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <fedechi...@gmail.com>
Subject Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner
Date Fri, 13 Jan 2006 12:30:13 GMT
Ok, I'll create a new Issue in jira, it's the first time I do it, so I hope to do all right.
  ----- Original Message ----- 
  From: Trustin Lee 
  To: Apache Directory Developers List 
  Sent: Friday, January 13, 2006 1:10 PM
  Subject: Re: [MINA] Apparent DEADLOCK in com.mchange.v2.async.ThreadPoolAsynchronousRunner


  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