Thanks Filip.
- I think there's a bug with maxKeepAliveRequests. Each call to
Http11NioProcessor.process() resets the keepAliveLeft parameter to the old
maxKeepAliveRequests value. When a parsing of a HTTP request doesn't have
enough input to complete the parsing stage, the process() returns
Socke
yes, with maxKeepAliveRequests you would also throttle the
connectionTimeout (or keepAliveTimeout, but that may be in 6.0.20) to
reduce the amount of objects.
I think you have a very valid use case, so I will add in some features
around managing the size of these objects to ensure they don't ove
Yes I am referring to the Http11NioProcessor objects. Playing with the cache
size did not help, since I had to deal with ~7000 registered
Http11NioProcessor objects (by registered I mean the object becoming a JMX
managed object). That amount by itself consumed a lot of the old gen space
(around ~60
hi Sagi, are you referring to the Http11NioProcessor objects?
If so, you should be able to configure the cache size when connections
are released. So you could also use maxKeepAliveRequests to limit it
do you have the memory dump available?
Filip
sagi tomcat wrote:
Hello,
I am using Tomcat
Hello,
I am using Tomcat 6.0.18 in a production server, serving thousands of users
and hundreds of transactions per second. I am using the NIO connector. I've
noticed a serious memory utilization problem which were traced to the fact
that a single processor is dedicated to a connection and is not
