Luis Neves wrote: >> It is my understanding that MINA will stop requesting incoming data >> from the OS when you call suspendRead. >> Eventually, the OS'es buffer of incoming data will be full and TCP >> will ask the other side to stop writing. > > Yeah... my problem is with the "eventually" part, I really need a > suspendReadNow(). > > If all else fails I will have to figure out a way of doing this at > the protocol level.
Surely all you need is sensible protocol level flow control? Do this:- Get your sender to send a small number of simultaneous requests (your flow control window) - say 5. Then make the sender stop sending until it's got a response, keeping 5 outstanding requests on the wire. You should then implement a similar setup on the consumer just to handle badly behaving clients, reading total <window size> number of msgs before you suspend reads and resuming reads when you send a response. Only once you have proper flow control can you start to throttle, otherwise you'll get flooded with msgs & end up with out of memory condition. If you rely on tcp buffers for flow control then be prepared for a huge amount of data being buffered. Far better to do it at protocol level. I've been experimenting with throttling by queueing a runnable (in a scheduled thread pool executor) that free's a window slot on the flow control window on the server after x milliseconds & resumes reads. It seems to work ok. Tested up to 12k msgs/sec. -- Ian Cass
smime.p7s
Description: S/MIME cryptographic signature
