[jboss-jira] [JBoss JIRA] Resolved: (JBWEB-202) Jboss acceptCount parameter works incorrectly

[Remy Maucherat (JIRA)]

     [ https://issues.jboss.org/browse/JBWEB-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBWEB-202.
----------------------------------

    Resolution: Rejected


The default is supposed to provide the best behavior, and we've determined that a production server ultimately scales and works better without waiting there. Low memory has the opposite behavior since it has to use a very small amount of threads, so waiting becomes mandatory.

But every use is different, and you can tune this very precisely by setting an executor based thread pool (which could block waiting for an available thread, etc etc).

> 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