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?
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.
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.
There are a few more questions, but things are little mixed up at my
end. Shall send them out soon...
thanks
ashish
On Mon, May 10, 2010 at 8:46 PM, Emmanuel Lecharny <[email protected]> wrote:
> On 5/10/10 4:52 PM, Michaël Figuière wrote:
>>
>> Here are some thoughts :
>>
>> As you mentionned, buffer design is tightly linked to the codec filter and
>> stream API mina will offer to users. The current ProtocolEncoder/Decoder
>> interfaces :
>>
>> void encode(IoSession session, Object message, ProtocolEncoderOutput out)
>> void decode(IoSession session, IoBuffer in, ProtocolDecoderOutput out)
>>
>> would give, with Stream<K>, something like :
>>
>> void encode(IoSession session, Stream<I> in, Stream<O> out)
>> void decode(IoSession session, Stream<I> in, Stream<O> out)
>>
>> Note that this looks pretty clear at the first sight for the user. The K
>> parameter in Stream<K> would in practice be :
>>
>> * a ByteBuffer or a ByteBuffer array for the in stream of decode() and out
>> stream of encode() for the outermost codec filter
>> * a Pojo for all the other streams
>>
>
> This is pretty much what is described here :
> https://cwiki.apache.org/confluence/display/MINA2/MINA+3.0+Design
>>
>> Now, if we consider these Stream objects as blocking queues,
>
> That would be a problem in the decoder, if we are blocking while getting a
> byte from the incoming Stream. We should be able to get data from the stream
> until the point we have nothing more remaining, then we have a way to quit
> the loop properly.
>
> If we were blocking, we would consume a thread until the data is flowing
> again, and we don't want threads to be waiting in MINA. Let's say that this
> design works well when you have a 1-1 relation between a socket and a
> thread, but not in our case.
>
>> In this scenorio, expecting ByteBuffer arrays and not just ByteBuffers as
>> parameter of Stream seems to be a prerequisite to allow message reordering
>> (once again for QoS, or just due to some protocol logic), as complex
>> messages may be written in several ByteBuffers.
>>
>
> yes, but the BB will be ordered in any case. We will read BB one by one
> anyway, so I don't think we should allow an array of BB to be added in such
> a Stream.
>>
>> Here, Stream would actually become a extended remplacement for IoBuffer.
>>
>
> Yop.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.nextury.com
>
>
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
