[
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.
