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 questions. Regards, Ussama -- 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.
