https://bz.apache.org/bugzilla/show_bug.cgi?id=62635
--- Comment #3 from Mark Thomas <ma...@apache.org> --- This discussion is heading towards something that would be better held directly on the dev@ list. HTTP is not designed for the communication style you describe. The only model that us guaranteed to work is: - client writes request - server reads all of the request - server writes all of the response - client reads all of the response Anything else is going to be fragile depending on exactly what components (proxies, caches, etc.) site between the client and the server. The sort of communication you describe would work much better with WebSocket. Tomcat does maintain an output buffer at the network level and in the situation you describe it is not flushed. However..., I've been thinking some more about this and I might have a non-invasive patch that would allow flushBuffer() to trigger a non-blocking flush if non-blocking I/O was in use. Let me dig out the test I wrote for this and see how it copes... -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
