https://issues.apache.org/bugzilla/show_bug.cgi?id=50495
--- Comment #3 from Mark Thomas <ma...@apache.org> 2011-01-04 10:38:25 EST --- (In reply to comment #2) > I have no idea when data is written to a socket from Tomcat. This is open source. You could have looked it up. The users list is always very helpful to folks trying to understand Tomcat's internals and needing a few pointers. The short version is: 'out' -> 8k buffer -> socket > I need to know when you write messages "under Tomcat control" - this is all I > need. It depends. The above buffer is flushed if it is full or if a call is made to out.flush(). Once the buffer is flushed, Tomcat has no control over the data. > I am sure you have some concept of "client message queue". As I said before, Tomcat has no concept of a message so there is no message queue. The bytes are treated as just that - bytes. There is nothing the delimits messages which are an application defined concept. If there are 5,000 bytes to be written the client, Tomcat has no idea if they represent 10*500 byte message or 1000*5 byte messages. > This is an a enhancement to address a bug in my opinion. As of now, a single > client has the ability to deplete resources of the whole server. That shouldn't happen. The NIO connector uses simulated blocking so the call to out.write() should block if the socket send buffer is full. If memory serves me correctly, that is around 30k. If you have a simple test case that demonstrates an OOME then please re-open this issue, attach it and someone will take a look. > This makes Tomcat Comet technology a toy for college projects at best. > Completely unsuitable for production application. That sort of comment isn't going to encourage any of the folks here (who are all volunteers) to help you. > I have no choice but to look for alternative implementations. You are, of course, free to do that is you wish. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- 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
