Bug 44199 - expose current backlog queue size
Summary: expose current backlog queue size
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: Other All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2008-01-10 05:02 UTC by Andrew Skiba
Modified: 2017-04-04 19:19 UTC (History)
0 users

contribution patch (5.68 KB, patch)
2008-01-10 05:03 UTC, Andrew Skiba
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Skiba 2008-01-10 05:02:28 UTC
I want to contribute a custom SocketFactory allowing to analyze the utilization
of acceptConnection attribute of a Connector. In a properly configured
production system, there should be rare situations where connections wait for a
worker thread to be handled. Our client complained on high latency of web
requests, but the measurement on servlet did not show high latency. So we wanted
to know the number of connections which wait in socket backlog and were not
accepted yet.

I solved this problem by writing a custom SocketFactory, which accepts
connections immediately and puts it in my queue until a call to accept() will
take them. So the number of waiting connections can be monitored via JMX.

To activate this factory, the declaration of the corresponding Connector in
server.xml should be changed like in the following example.

 <Connector port="8080" maxHttpHeaderSize="8192"
               maxThreads="10" minSpareThreads="5" maxSpareThreads="7"
               enableLookups="false" redirectPort="8443" acceptCount="10"
               connectionTimeout="2000" disableUploadTimeout="true"


No changes in existing classes are required.

Please review the code in the attachment.
Comment 1 Andrew Skiba 2008-01-10 05:03:18 UTC
Created attachment 21373 [details]
contribution patch
Comment 2 Mark Thomas 2017-04-04 19:19:55 UTC
The code has moved on since this patch was provided. Applying it - or something like it - would require significant refactoring.