Just a clarification : Chad, I don't want to fell like I'm arguing. I'm really trying to see if the change I have pushed should be made optional, and if doing so will really help when we are dealing with a congestion situation.
What I dont get is how waiting for the select() to wake up the thread when the socket is ready to write is any different from what I'm doing. Do you have any link that explaining the pb ? Thanks ! Le 1/8/13 4:46 PM, Emmanuel Lécharny a écrit : > Le 1/8/13 4:06 PM, Chad Beaulac a écrit : >> Understood on change in state between writable event firing and socket could >> close by the time you goto write. In which case the read event would fire >> next and result in zero bytes read signaling the socket is closed. >> >> Your statement below is exactly what I have dealt with on many systems. >> Resulting in TCP buffer overflow and RAM bloat/leak. >> "One possible case would be if the underlying OS were to accept anything >> you try to write into the socket..." > In my understanding, you can mitigate such pb by setting the > SO_SNDBUF,accordingly to your client capacity. At some point, if your > client is slow, you perfectly can ends with your server being swamped > with data waiting to be sent, but I don't see hav using a queue can help > here : as soon as the socket will refuse to accept anymore data than the > buffer it uses to store the data, you are safe. > > In other words, your application should take care of such scenario, or, > better for MINA to provide the tools to inform the application when the > sending queue is getting too large... > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
