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

[Dmitry Murashenkov (JIRA)]

    [ https://issues.jboss.org/browse/JBWEB-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609958#comment-12609958 ] 

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