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

[guillermina galache (JIRA)]

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

guillermina galache commented on JBWEB-202:
-------------------------------------------

Hi, I need know how i can set LOW_MEMORY setting,  that i need the old acceptcount behavior. 
Could you helpme please?

Thanks!!!!


> 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