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 Sat, 06 Oct 2007 19:35:25 GMT

Mike wrote:
When MINA 2.0 writes pending messages, it loops until either all the 
pending message have been written to the OS or until it can't send any 
more data without blocking because the OS' write buffer for the socket 
is full.  So, MINA is receiving each of your individual ByteBuffer (now 
IoBuffer) objects and writing them in rapid succession.  This allows the 
operating system to send all the data in a single IP packet regardless 
of the tcpnodelay setting.  MINA is not doing any mering of your 
messages.  The operating system is doing this.  IIRC, MINA 1.x will 
write a ByteBuffer and then resume writing once the data in the 
ByteBuffer is flushed by the OS.  So, MINA 2.0 is much more efficient 
and can more effectively use the OS' write buffer.
You do bring up a good point that you can't flush the write queue from 
within messageReceived.  I'll file a JIRA issue for this.

Thanks Mike.  This is exactly my issue.  I do wish to be able to flush the
write queue from within mesageReceived.  I'm not building an application
from scratch.  What I'm doing is building a server/client application where
a sequence of calls/requests is dectated to have responses in a certain
order.  The number of requests vary but each request from the server which
in turn becomes a client call back to the originating server has to get a
response.  The way mina 1 handled it suit my needs.  I'm unable to think of
another way apart from reimplementing some of the mina filters which I
usually try not to do.  

It would be ideal to have a an overriden IoSession.write() method that would
allow for automatic flushing of the queue after each write (mina 1.x style)
as opposed to writing the objects in rapid succession before flushing (mina
2.x style). My application uses the DemuxingIoHandler along with a few
codecs that will each be invoked in order depending on what is sent and/or
received (for example receiving new server requests as opposed to receiving
confirmation messages for client requests).  This way, I'm able to control
the request/response cycle and step through the messages in order, thus
acheiving unique request/response cycles.  

You said that you were going to file a JIRA issue for it but I didn't see it
yet.  I'd be more than happy to file one if you wish.  Just let me know. 
Because MINA is designed for efficiency, this might not make sense at first,
but what I'm trying to write is an application that can still use MINA in a
stepwise way (leveraging nio architecture) allowing my application to scale
very well as thousands of requests are received by the server.

Real quick, here is a step-by-step scenario.

I have written 2 codecs; let's call them ServerCodec and CommandCodec.  More
codecs may be added soon.

1- Server receives initial request.  It invokes decodable on all codecs but
this time only the ServerCodec will match.
2- Server constructs the request received and extracts a multi-command
script to invoke.
3- In ServerMessageHandler.messageReceived(), I lookup a matching script to
invoke.  The script has a run(ioSession) method containing multiple commands
(here is when this server becomes a client to the requesting server that
sent the initial request).  Note that the underlying ioSession is passed to
the script.
4- At this time, let's assume that the script will issue 2 commands.
5- Script uses the ioSession to write command 1 which is automatically
encoded appropriately and flushed.
6- Server receives command 1 and issues a confirmation message received by
the appropriate decoder.
7- Script then issues command 2 and the confirmation is returned.  This is
the end of the script.
8- Control returns to the original messageReceived() method and the
execution of the who scenario ends.

There is a chance that this can be designed differently.  I'd be interested
in learning about other ways to achieve the same sequence of events as
outlined using ioFilters, ioHandlers or any other way.  If not, having a
flush() available from within messageReceived will also solve my current
implementations delima!  And that is why a JIRA issue regarding this sounds
like a good solution at this time :)

Hope this makes more sense.  Please let me know if you have any other

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

View raw message