[jira] [Updated] (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-489: -- Fix Version/s: (was: 2.0.6) 2.0.8 > 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 >Assignee: Mark Webb > Fix For: 2.0.8 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-489: -- Fix Version/s: (was: 3.0.0-M1) 2.0.6 > 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 >Assignee: Mark Webb > Fix For: 2.0.6 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-489: -- Fix Version/s: (was: 2.0.0-M4) 3.0.0-M1 This is a major improvement, but it will be done in 3.0 > 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 >Assignee: Mark Webb > Fix For: 3.0.0-M1 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-489: -- Fix Version/s: (was: 2.0.0-M3) 2.0.0-M4 > 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 >Assignee: Mark Webb > Fix For: 2.0.0-M4 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080723-2.patch Patch against 'buffer' branch with example of concatenating Strings with a CompositeByteArray. > 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-M3 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080723-1.patch Patch against 'buffer' branch which fixes issues using get/put on larger 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-M3 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch, mina-composite-20080723-1.patch, > mina-composite-20080723-2.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-489: -- Fix Version/s: (was: 2.0.0-M2) 2.0.0-M3 > 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-M3 > > Attachments: mina-composite-20080515.patch.gz, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080521-2.patch This patch is against the code in the 'buffer' branch. - Added slice() operations. - Added skip() operations to relative readers and cursors. (Sorry about patch spam! I'm just aware that this area is being actively worked on right now, so I'm trying to provide any useful functionality as I develop it.) > 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, > mina-composite-20080517.patch, mina-composite-20080521-2.patch, > mina-composite-20080521.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080521.patch This patch is against the code in the 'buffer' branch. - Added support for all primitive types (and wrote a basic test). - Added ByteArray.equals() method (not yet tested). > 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, > mina-composite-20080517.patch, mina-composite-20080521.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080517.patch (Updated patch - previous version was patch against already-patched code, not against trunk.) > 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, > mina-composite-20080517.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Dougherty updated DIRMINA-489: --- Attachment: (was: mina-composite-20080517.patch) > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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-20080517.patch Updated patch: - improved tests and fixed bugs - got autoFlush working (at least for a simple test) - add putInt() method - change start()/length() to first()/last(), to make meaning clearer - altered CursorListener interface > 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, > mina-composite-20080517.patch > > > 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.
[jira] Updated: (DIRMINA-489) Composite IoBuffer
[ 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.
