How do I migrate the connector thread settings in JBoss 5.1.0 to web subsystem in JBoss 7.1.1 ?

[ejroberts]

I am trying to migrate the connector thread settings we have in our JBoss Web config in JBoss AS 5.1.0 (i.e. deploy/jbossweb.sar/server.xml) to the format

that achieves the same end in JBoss AS 7.1.1.

Here is a snippet from the 5.1.0 server.xml file which I would like to migrate over

<!-- A HTTP/1.1 Connector on configurable port -->

<Connector protocol="HTTP/1.1" scheme="http" port="8080" address="${jboss.bind.address}"

         maxThreads="50" minSpareThreads="5" strategy="ms" maxHttpHeaderSize="8192"

         emptySessionPath="true"

         enableLookups="false" redirectPort="8443" acceptCount="100"

         connectionTimeout="60000" disableUploadTimeout="true"/>

Unless I am mistaken, in 7.1.1, the web subsystem only provides a subset of the attributes above. The ones I am having difficulty finding

homes for are highlighted in red above.

I have seen that there is an executor attribute which I believe links to a Thread Pool definition within the threads subsystem configuration, which

might solve the majority of what goes where, but I need some help understanding if they are correct.

Here is the current snippet from my 7.1.1 standalone.xml. I opt for a bounded queue thread pool as we clearly had task limits via the acceptCount before.

Does strategy from the old format simply not have any part in the new configuration ? How about emptySessionPath ?

<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">

     <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="8443" max-connections="100"/>

</subsystem>

<subsystem xmlns="urn:jboss:domain:threads:1.1">

     <bounded-queue-thread-pool name="http-executor">    

          <core-threads count="5"/> <!-- is this the same as minSpareThreads? -->

          <queue-length count="100"/> <!-- is this the same as acceptCount? -->

          <max-threads count="50"/> <!-- is this the same as maxThreads and if so does it override max-connections in the connector definition? -->

          <keepalive-time time="60000" unit="milliseconds"/> <!-- is this the same as connectionTimeout? -->

     </bounded-queue-thread-pool>

</subsystem>

Thanks for any help

(p.s. an unrelated question, should redirect-port in the connector definition really be something like redirect-socket-binding in order to reuse the https socket binding definition ?)

[jfclere]

strategy="ms" apply to the threads handle ms was the default .

In fact there were 2 "lf" and "ms" only ms has been kept.

Using an executor allows you to choose different threads models for the connector threads.

emptySessionPath="true" is gone but you can define the <SessionCookie Path="/"/> in the webapp. (See https://community.jboss.org/message/497671#497671).

redirect-port may refer to port on Apache httpd (front-end)... There is a JIRA for that (AS7-4295).

acceptCount is the backlog now that is fixed to 100.

ConnectionTimeout is soTimeout the default is 60000 ms It could be set via org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT

[ejroberts]

Hi Jean-Frederic!

Many thanks for the response, much appreciated.

Does that mean the executor attribute and connecting max-threads attribute in the thread pool definition is mutually exclusive with the max-connections attribute ?

If acceptCount is now a fixed backlog setting (not exposed?), what does the queue-length element do in the thread pool definition ?

I found the org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT (and also org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT) system property that you suggested, and noted that

this is working as of JBoss AS 7.1.2.Final (EAP).

I hear what you are saying about the redirect-port, I guess there should be two mutually exclusive attributes then for the correction. Thanks for the jira link.

Thanks again!

[jacobmarcus20]

Hi Ed,

I read the code to understand how bounded queue thread-pool handles queue length. Once core threads are all busy (in your case 5), new requests are parked in the queue if space is available in the queue. Only after the queue becomes full, additional threads are created based on the max-threads configuration. So the way this bounded queue thread pool behaves is slightly different from how the old connector behaves.

I tried giving a very small queue length of one and it seems to behave more like the way I wanted. Hope this helps.

cheers,

[redditor]

I guess I need some definitive clarification.  Is the acceptCount/backlog attribute now controlled by the queue-length attribute?

[jfclere]

No backlog is fixed to 100  (511 incase of NIO2).