[
https://issues.jboss.org/browse/JBWEB-202?page=com.atlassian.jira.plugin....
]
Dmitry Murashenkov commented on JBWEB-202:
------------------------------------------
Thanks for reply! We will try executor approach.
I think this behavior of acceptCount (and general server behavior concerning connections
acceptance and rejection) should explicitly mention these peculiarities in documentation.
Also let me explain our case as it may be useful for other people who can run into this
problem:
Although this behavior only affects new connections establishment, which is rare in http
1.1 because of keep alive, we are using Jboss behind Nginx proxy which is at the moment
only capable of http 1.0 connections to backend servers. And so each http request arriving
at proxy is transformed into new http connection to Jboss. So thread count should be set
taking this into account.
Jboss acceptCount parameter works incorrectly
---------------------------------------------
Key: JBWEB-202
URL:
https://issues.jboss.org/browse/JBWEB-202
Project: JBoss Web
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tomcat
Affects Versions: JBossWeb-7.0.0.Beta11
Environment: APR connector is enabled (but seems that same bug is reproduced
without it)
Reporter: Dmitry Murashenkov
Assignee: Remy Maucherat
Labels: acceptCount, by, connection, jboss, peer, queue, request, reset,
socket
We've found behavior of acceptCount property quite unexpected in JBoss 6. Seems that
code is same in the latest repository revision.
TC is very simple:
1. Set connector properties:
<Connector ...
maxThreads="1"
acceptCount="100"/>
2. Send several http requests (few will be enough - 4-5 requests) to server in parallel.
We performed load testing when found this bug, so we just started the load client which
tried to make several connections and send a single request through each.
Expected result: all requests get handled within some time (because acceptCount is quite
high - far bigger than the number of requests)
Actual result: several requests receive "Connection reset by peer"
The actual problem seems to be in AprEndpoint$Acceptor.run():
if (!processSocketWithOptions(socket)) {
Socket.destroy(socket);
}
Method processSocketWithOptions() invokes getWorkerThread() which returns null if no
thread is available (at least by default - in LOW_MEMORY setting is not set) and so the
socket is destroyed even though acceptCount number of incoming connections is not
reached.
Of course formally connection is accepted in the first place and only then is closed, but
actual outcome of this case is that connection is closed and cannot be used which is quite
unexpected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira