thanks for the warning - is anyone actively working on this issue ?
It's important to my project to be able to slice buffers ( actually,
I have one permanent buffer, with permanent "slice" buffers pointing
to bits of it and when the contents of the buffer change I send a
load of network messages - one for each of the slice buffers - this
avoids any copying or reallocating buffers ).
If no one else is working on this I'll probably give it a go myself,
but I would appreciate some advice about why it was considered a bad
idea for view buffer "containers" (mina ByteBuffer) to be pooled -
can anyone help me out here ?
josh
On 15 Feb 2006, at 20:05, <[EMAIL PROTECTED]> wrote:
I tested my own patch to DIRMINA-165 and I admit that it is very
very bad, please don't use it.
I'm not sure of the why of the bad-working of those classes, but
I'm sure that they simply don't work.
For the reason please wait for the answer of someone else.
by Federico Bonelli
----- Original Message ----- From: "Joshua Portway" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 15, 2006 6:43 PM
Subject: [mina] DIRMINA-165 revisited
Hi,
I've been looking at the code submitted for this bug (to allow the
creating of read-only buffers and buffer slices) and reading the
comments, and I'm not sure I understand why the submitted patch is
considered "dangerous". Trustin advises that all the methods
assert that every buffer involved is not pooled, but I'm not sure
why this should be - presumably, assuming that any derived
buffers maintain a reference to their parent buffer, the parent
buffer won't be returned to the pool until all derived buffers
have been released, and therefore released it in turn. Am I
missing something here ?
josh
