[ http://issues.apache.org/jira/browse/DIRMINA-165?page=comments#action_12370069 ]
Federico Bonelli commented on DIRMINA-165: ------------------------------------------ I agree about keeping autoExpand "false" after a duplication. Personally I thought a lot about this problem, and I suggest having a refCount object, shared between all the copies and the originalBuffer (I consider the original as a copy like the others), and having an unshared refCount, used privately by each copy. SharedRefCount should be an object wich has a reference to the original nio.bytebuffer. Then, when we create a copy, its own refCount is set to 1 by default, and we should give the copy the sharedRefCount increased by 1. When an acquire() or release() method is invoked it will increase/decrease the private refCount and the sharedRefCount. In this way, whenever calling a release(),and the privateRefCount goes to zero, we check if the sharedRefCount is higher than zero, and we simply discard the underlying nio.bytebuffer (because it is a copy). Instead, if the sharedRefCount is zero, we discard, as usual, our nio.bytebuffer, and then we pool the original nio.ByteBuffer, obtained from our sharedRefCount. This way of doing should be effective with duplicate() and asReadOnly() methods, because we are sure we don't pool any of the copied nio.bytebuffers that are dangerous to be used, and we manage the privateRefCounts properly. WDYT? > Easy and performant copy of the ByteBuffer > ------------------------------------------ > > Key: DIRMINA-165 > URL: http://issues.apache.org/jira/browse/DIRMINA-165 > Project: Directory MINA > Type: Improvement > Versions: 0.8, 0.9, 0.8.1, 0.8.2 > Reporter: Federico Bonelli > Priority: Minor > Fix For: 0.9.3 > Attachments: ByteBuffer.java, HubServer_broadCastTCPmessages.zip > > Until now if you wish to broadcast a message you must create by your own the > bytebuffer copies, it would be better to provide a ByteBuffer.asReadOnly() > method that create a copy that share the data with the original ByteBuffer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
