mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ubaggili <ubagg...@jinsys.org>
Subject Re: how to guarantee flushed write in encoder - mina-2.0.0-M1-snapshot
Date Fri, 05 Oct 2007 12:57:09 GMT

Thank you Niklas.

I understand your point.  However, I'm not trying to set TCP boundaries. 
What I'm trying to do is write requests back to the server during a

Here is a clearer example.

1- Server X receives a request from client Y.
2- Server X processes the requests and now has to use the same ioSession to
feed back little requests to the initiating client Y.
3- Server X encodes those requests as shown in the email below and writes
them back to Client Y.  Client Y sends a confirmation code with each
received request.
4- Server X goes through all pending requests, untill last one is sent and
confirmation is received.
5- Server X then is done and the originally received connection (session)
can be closed.

Mina 1.X had a different implementation of the "out.write()" as it seemed
flush those in a timely manner.  Mina 2.x's implementation seems to want to
optimize all write requests that are part of the response and groups/merges
them together at times but not other times.  Even if I "pause" for 5 seconds
between write requests, it is not until the messageReceived method exits
that the buffers are flushed - or so it seems.  In other words, the
underlying nio buffer doesn't get written to until that whole chunk of code
It would be nice if there is a setting that can allow for the mina 1.x style

Any thoughts on this would be greatly appreciated.  Even if the
implementation of the sequence outlined above can be performed though other
mechanisms using filters, ioHandlers, etc..  The only requirement that I
have is to use the same channel to the client to feed back requests and
receive the corresponding responses.


Niklas Therning wrote:
> ubaggili wrote:
>> Hello.
>> I have spent a lot of time trying to figure out how I can write and flush
>> "abc" through the ProtocolEncoderOutput but I have been unsuccessful.  I
>> must be missing something too obvious as usual!
>> In Mina 1.1.2, there was no issue with this.  I would be able to send off
>> "abc" and "def" and they would get sent as 2 packets.  With Mina-2.0-m1,
>> I'm
>> unable to do so.  I have tried every trick and flip and flush, but I
>> haven't
>> been able to reliably solve this.  In some cases, the 2 messages are sent
>> off separately but in as many others they are sent off as one packet. 
>> I've
>> even set the tcpnodelay property to false (which seems to be counter
>> intuitive) but that wasn't it either.
>> Any hints would be greatly appreciated.  Here is my sample code:
>> public class AgiCommandEncoder implements MessageEncoder {
>> ...
>>     public void encode(IoSession session, Object message,
>> ProtocolEncoderOutput out) throws Exception {
>>         CommandRequest agiCommandRequest = (CommandRequest) message;
>>         byte[] commandAsBytes = commandRequest.getCommand().getBytes();
>>         IoBuffer buffer = IoBuffer.allocate(commandAsBytes.length,
>> false); 
>> //<==== IoBuffer is the new-old ByteBuffer in trunk
>>         buffer.put(commandAsBytes);
>>         buffer.flip();
>>         out.write(buffer);
>>     }
>> ...
>> }
>> This encoder is registered as part of the DemuxingProtocolCodecFactory
>> extended object.
> I'm afraid I cannot answer how to achieve what you want. If your
> protocol is TCP based I think it is dangerous to have a protocol which
> is dependent on packet boundaries. AFAIK there is no way (at least not
> in Java) to specify exactly what bytes should go in the same TCP packet.
> If you are designing your own protocol you should consider introducing
> some kind of boundary. That will make your protocol independent of how
> the lower layers of the network stack decide to fragment the packets.
> -- 
> Niklas Therning
> www.spamdrain.net

View this message in context: http://www.nabble.com/how-to-guarantee-flushed-write-in-encoder---mina-2.0.0-M1-snapshot-tf4568900s16868.html#a13058757
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

View raw message