Skip to main content  


SPR # NORK65PNF3 fixed in 6.5.5; 6.5.4 FP1 releaseRecommended Release (14.0 FP1)

Product Area: Server Technical Area: Web Server Platform: Cross Platform

Regression in 6.0

SPR# NORK65PNF3 - When moving from Domino 5.x to 6.x, the HTTP thread management model was changed. With the 5.x model, each thread managed one request at a time. In 6.x, the model was changed so that each thread could have a queue of requests. With this change in 6.5.4 FP1, and 6.5.5, we are allowing the option to change how threads process HTTP connections. The original R5.x model or R6.x queue of requests model can be selected.

Use the following Notes.ini settings for these changes:
HTTPQueueMethod=0 - This setting is the default, and represents no change in queueing from the R6.0 and above. The accept thread will evenly distributed network connections to all worker threads using a round robin method. Connections are assigned to a specific thread.
HTTPQueueMethod=1 - This setting will cause the accept thread to find the worker thread that has the least number of network connections assigned to it and assign the new network connection to that worker thread. It is still possible that a new network connection may be assigned to a thread that is in the process of processing a long running request. It is recommended but not required that persistent connections are disabled when using this option to get the maximum effect. This will limit the possible wait time if a new network connection is queued to a thread that already is busy with other connections(s)
HTTPQueueMethod=2 - This setting will cause the accept thread to put the incoming network connections on a queue from with the worker threads will pull from. This is the same model as R5. It is also recommend but not required that persistent connections be disabled when using this option to get the maximum effect.

In general the best method to use will depend on the nature of applications running on the server. If the mix of URL requests presented to the server run very quickly then option 0 or 1 will be the best option. Option 1 performs a little better then option 0 but at a slightly higher CPU cost so if URL requests are CPU bound then option 1 may actually slow overall through put of the server. The slowest option is option 2 with regard to overall server throughput, however if the mix of URL requests include very long running requests such as large uploads/downloads or URLs that run application code the this may be the best option for the customer.

APAR: LO04665
What is an APAR?

Last Modified on 12/09/2013

  Document options
Print this document
Print view

Search Advanced Search

  Fix list views

 RSS feeds   RSS
Subscribe to the fix list

Using this database
View notices

  HCL Support
HCL Support

    About HCL Privacy Contact