Geek Answers Handbook

Relationship between the HTTP.sys request queue and the IIS application pool

I read this from <IIS 7.0 Resource Set>

HTTP.sys maintains a request queue for each workflow. It sends HTTP requests to the request queue for a workflow that serves the application pool in which the requested application is located. For each application, HTTP.sys supports a single entry URI namespace routing table. The routing table data is used to determine which application pool is responding to requests from parts of the namespace. Each request queue corresponds to one application pool. And the application pool corresponds to one request queue in HTTP.sys and one or more worker processes.

The bold parts confused me. I understand: HTTP.sys matain is a request queue for each workflow. An application pool can have one or more workflows. Therefore, the application pool must also correspond to one or more request queues. Why only one in a bold sentence?

And btw, can someone give a clearer explanation of the table of the URI name routing table table ? Some examples would be better.

Thanks.

0
source share
4 answers

I am struggling with the same question ... but I think the process is as follows:

  • Request intercepted by HTTP.sys
  • HTTP.sys makes initial contact with WAS
  • I read ApplicationHost.config and passed it the WWW service.
  • WWW service configures HTTP.sys (from now on, HTTP.sys has configured the appropriate application pool queue, I think)
  • HTTP.sys checks if the workflow is accessible (WAS contacts via WWW), if not, the request is stored in the application queue.

=> if the workflow is available, the request is now redirected to the correct work pool

If the workflow is not available, the request is stored in the application queue. HTTP.sys will now notify WAS (via the WWW service) that a new request has been added to the queue. The WWW service will ask for WAS for the workflow. WAS will spawn one, and let WWW know that an application pool has been created. Now the WWW can pass the request to the appropriate workflow (adding it to the queue). Then WWW will let HTTP.sys know that the workflow is spawned, so the next HTTP.sys request can forward the immmediatly request ...

I'm not quite sure that this is technically all right, so if someone can fix / confirm this, it will be great!

+1
source

To discuss a paragraph in a book, you must provide additional information.

This item comes from the IIS 7.0 Core Components section, and the version in Safari Books Online is different from what you inserted.

HTTP.sys maintains a request queue for each workflow. It sends HTTP requests, which it receives in the request queue for a worker process that serves the application pool in which the application is requested. For each application, HTTP.sys supports a single-entry URI namespace routing table. The routing table data is used to determine which application pool is responding to requests from which parts of the namespace. Each request queue corresponds to one application pool. An application pool corresponds to a single request queue in HTTP.sys and one or more worker processes.

So, the last sentence should be understood as

  • The application pool corresponds to a single request queue in http.sys.
  • An application pool corresponds to one or more workflows.

Therefore, your understanding of “HTTP.sys supports a request queue for each workflow” is incorrect. The correct one should be "HTTP.sys supports a request queue for each application pool." Therefore, no matter how many worker processes exist for one application pool, they only service requests from the request queue in http.sys.

"For each application, HTTP.sys supports single-entry table namespace URI routing."

I think it should be "for each application pool , HTTP.sys supports a single-entry URI namespace routing table." This routing table makes it easy to send requests (whose URL is clear) to pools. Very similar to a hash table.

A table can be built from the <sites> in applicationHost.config, by combining sites, their bindings, applications, and their pooling of application pools. There is no additional information from Microsoft about the exact structure of the table.

+1
source

The listener needs to receive messages. To do this, he needs to open the socket (or channel descriptor or start reading MSMQ, etc.). However, in order to receive the correct messages, he needs to obtain the necessary address information from WAS. This is done during listener startup. The protocol listener adapter calls the function on the interface of the WAS listener adapter and, in essence, says: "Now I am listening to the net.tcp protocol, please use this set of callback functions, I will tell you to tell me what I need to know." In response, WAS will call back with any configuration that it has for applications that are configured to receive messages using the protocol in question. For example, a TCP listener will be informed that there are two applications (*: 7777 / Foo and *: 7777 / Bar) configured to use TCP. WAS also assigns each application a unique listener channel identifier used to associate requests with their target applications. The listening process uses the configuration information provided by WAS to create a routing table that it will use to map incoming requests to listener channel IDs as they arrive.

0
source

An application pool can have one or more workflows.

This is not true 1 Application Pool = 1 Workflow

-2
source

More articles:


All Articles