FYI On windows xp, I have encountered a problem with byte buffers that wrap arrays. I have used them to wrap preexisting arrays in AsyncObjects framework in order to avoid unnecessary data copying. I thought that it is an optimization.
However after I have written IO intensive test to check this, I have encountered an OutOfMemoryError on JDK 1.5.0_04 because ScocketChannel was allocating direct buffers for each write and read operation if wrapper buffers are used. Because of this I have switched to direct buffers in my framework when I have identified the bug. Looking at MINA and Grizzly docs suggests that result might be different for other platforms. At some future version I will make a option that specifies which buffers should be used. If direct buffers will be abandoned in the MINA 2.0, a similar problem might be encountered for that version. I suggest to consider a fallback option just for such case. Doing things more slowly could be better that failing with OutOfMemoryError. Constantine On 5/24/07, peter royal <[EMAIL PROTECTED]> wrote:
On May 23, 2007, at 4:19 PM, Pérez Paz Luis Alberto wrote: > Is necessary disable the direct buffers on the 1.1.0 version?? > I mean: > ByteBuffer.setUseDirectBuffers(false); > ByteBuffer.setAllocator(new SimpleByteBufferAllocator()); yes > I was looking in the changes between version and I've not found > anything about. the changes between 1.0 and 1.1.0 are minimal -- replacing the util.concurrent backport with Java 5's java.util.concurrent. > Is a good idea to add an ExecutorFilter in a SocketConnector > (client) taking into account that my protocol codec filter is doing > cryptographic operations?? Yup. Rather, I don't see doing crypto-work as a reason unto itself as to (not) use an ExecutorFilter. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
