Forwarded to the ML...
On Mon, May 10, 2010 at 1:51 PM, Emmanuel Lécharny<elecha...@apache.org> wrote:
On 5/13/10 10:01 AM, Ashish wrote:
Sorry for reverting a bit late
Here are my confusion
1. We talked about removing IoBuffer interface and using ByteBuffer
directly. Is this what are implementing or we plan to keep IoBuffer?
We don't want a wrapper around ByteBuffer if it's just to offer a way to
extend the buffer. You have to understand why IoBuffer has been created from
day one : ByteBuffer cannot be extended (ie add more bytes than what were
allocated), and you can't extend (ie class MyBuffer extends ByteBuffer...)
ByteBuffer because the constructor is not public. So the IoBuffer has been
created, a wrapper around ByteBuffer just for this purpose.
IMO, it defeats the idea that a Buffer is just a temporary storage. It's
created once, and then used but not modified. By defining a class that
stores many ByteBuffers, but with methods that mimic the ByteBuffer class,
you can have a better solution, as you don't reallocate a new buffer each
time you want to extend it. So the idea is just to have a class in which you
concatenate the incoming ByteBuffers but that is seen as a single
ByteBuffer.
You put precise words to my thoughts :) Yeah we really don't need to
have all the methods of BB, but a class that
can give a unified view of Buffers. This is what was running in my
mind, but yeah I overlooked other API's in IoBuffer..
With IoBuffer, Users may implement their own buffer's. With direct
use of BB, we loose this. I am not sure if anyone would ever need to
implement
this, but its worth considering as remote possibility and reject it.
I hope I clarified the matter.
2. I am not sure if Zero copy is at all relevant here, but I am
confused. When we write back response, we usually use what's in the
Buffer, so how does it work? I am essentially mixing things here, but
in isolation its difficult to put things together.
Zero copy is important when you want to transfert large chunks of data to
the client. For instance, when writing a FtpServer, you don't want to read
the file from the disk into a temporary memory, just before writing it back
to the socket, unless you have some transformation to do on the data. In
this case, what you want to do is to directly read from the file and move
the data to the channel. The FileChannel API contains a transferTo() method
that does exactly that. We have to use it.
Hmm in this case our buffer's should not come in picture :) it should
go directly to the Channel.
There are a few more questions, but things are little mixed up at my
end. Shall send them out soon...
Hope it helps.
Yeah it does :)
There is lot of context switching happening at my end :(
I am really not able to put in the amount of effort I planned for 3.0 :(
Hope things will improve in future :)
thanks
ashish
