tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Максим Гумеров <>
Subject Re: acceptCount with NIO and Tomcat 8
Date Sat, 12 May 2018 02:21:14 GMT
> On 11/05/18 18:21, Максим Гумеров wrote:
> > Hi! I am running Tomcat 8 as part of Spring Boot application. As usual,
> > acceptCount defaults to 100 and maxThreads to 200. According to
> >
> configuration
> > I am expecting Tomcat to accept 200 "long" requests (each taking say 20
> > seconds to complete), then accept 100 more connections but not start
> > reading from them, and then reject any connection requests beyond that.
> > That's why this is the expected behavior: acceptCount = "The maximum
> queue
> > length for incoming connection requests when all possible request
> > processing threads are in use. Any requests received when the queue is
> full
> > will be refused." So, when first 200 requests are all taken by 200
> > processing threads, next 100 will go to the queue and subsequent will be
> > ignored. At least that's how it reads to me.
> >
> > But what I actually see on my Mac is, tomcat successfully accepts a
> little
> > short of 1000 such connections (I just didn't try more connections) made
> > within 5 seconds. It processes no more than 200 requests at a time, but
> > does not reject connections after 300th one, as one would expect.
> >
> > What's the explanation for that? Can the quoted documentation be
> imprecise
> > or outdated? Or am I missing something in it?
> acceptCount for NIO is passed in to ServerSocket.bind(SocketAddress,int)
> as the 2nd parameter (backlog). The Javadoc for that method says:
> <quote>
> The backlog argument is the requested maximum number of pending
> connections on the socket. Its exact semantics are implementation
> specific. In particular, an implementation may impose a maximum length
> or may choose to ignore the parameter altogether.
> </quote>
> It looks like it is being ignored in your JVM.
> Mark

Thank you, this looks like one possible explanation.
Maybe someone else will show me some other.

But, considering what you say, isn't that a documentation deficiency? They
shouldn't write "acceptCount is the length of connection queue" if it's
just a hint. Or, they could just add a note that actual queue length may be
chosen by implementation instead. Also, they shouldn't write " up to the
configured maximum (the value of the acceptCount attribute)", better
formulation is "up to connection queue size (based on acceptCount
attribute)". What's written there now simply contradicts the
implementation, right?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message