[jira] Updated: (DIRMINA-489) Composite IoBuffer

["Rich Dougherty (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rich Dougherty updated DIRMINA-489:
-----------------------------------

    Attachment: mina-composite-20080515.patch.gz

Attaching file from this message (http://www.nabble.com/Re%3A-Streams-and-disposal-of-ByteBuffers--Was%3A-Re%3A-Redesigning-IoBuffer...--p17251948.html), to make license approval explicit.

Note that ByteArrayList contains code I originally wrote for the Commons Collections project, although I lost the previous license headers somewhere along the way.

Excerpt from email:

Since my last email I've spent a bit of time playing around with a set of classes and interfaces that (hopefully) provide the sort of functionality that we talk about. They're not quite ready, but I think it might be worth sharing them, so you can consider them for your new branch.

I've attached the source for these files. They're not complete yet or very well tested (e.g. flushing doesn't work properly), but I think I'm reasonably happy with the design. Notably there's no mark/reset functionality, nor is there support for reading/writing a wide variety of types (just byte/ByteBuffer/int). These features should be easy to add. I just wanted to keep it as simple as possible initially.

The key thing I've done is factored the design into multiple classes and interfaces. This move away from a single, monolithic class is intentional. Having multiple classes allows users to pick the implementation that suits a particular usage. It also dramatically simplifies implementation since we can use lower-level classes to build our higher-level ones, rather than trying to do everything within a single class. e.g. Stream classes are much easier to write once a good composite buffer class has been written.

Here's a summary of the classes: (Names are just placeholders.)
- BufferByteArray: A class that wraps ByteBuffer, providing simple utility methods and especially a free method to support pooling.
- CompositeByteArray: There is a class with the same interface that supports multiple buffers with O(1) adding and removing.
- *ByteArray.Cursor: Stores position information for a ByteArray. Keeping this information separate makes the classes simpler, and gives users more flexibility (e.g. reading and writing at separate positions at the same time).
- CompositeByteArrayRelativeReader/Writer: Restrictive, relative-access-only stream interfaces, backed by a CompositeByteArray. The benefit of these stream interfaces is that they control access to the underlying buffers, and so can do certain things automatically for the user (e.g. freeing buffers).

Anyway the design should allow all the big features we've been talking about:
- zero-copy reads
- gathering writes
- optional asynchronous stream interface with auto-freeing/auto-allocating/auto-flushing of ByteBuffers

> Composite IoBuffer
> ------------------
>
>                 Key: DIRMINA-489
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-489
>             Project: MINA
>          Issue Type: New Feature
>          Components: Core
>            Reporter: David M. Lloyd
>             Fix For: 2.0.0-M2
>
>         Attachments: mina-composite-20080515.patch.gz
>
>
> Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data.
> It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified.
> The goal is to be able to process large messages with a minimum of copying.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.