The 

outgoingFilter

 get passed the request and reply object. Again, a call to a separate object 

called 

ReplyDataMover

 is made that recorded the rate that the output stream associated with 

the reply was returned from the server and passed to the client 

The 

exceptionFilter

 method get passed the request and HTTP Exception that resulted in it 

being called so the 

exceptionFilter

 that can catch any exceptions that occur in the processing 

of a request or reply. 

A number of obstacles had to be overcome in the design of the 

HTTPQoS

 filter so that the 

filter did not impact performance. These will now be discussed.  

5.2.1 Monitoring HTTP Message Content Length and Transfer Time 

To monitor the performance of a Web delivered service, determining the rate of data 

transferred from the end user to the target HTTP server and vise versa needs to be calculated 

for both http requests and replies. The amount of data in a HTTP message body can usually 

be determined from the 

Content length

 header field. However, sometimes this field is not 

propagated with information. For example, with chunked transfer coding, the 

Content length 

header

field is not used so some other method has to be used to determine the information. 

The time that the data transfer of the message body starts and finished needs to be recorded 

also to determine how long the transfer takes. To add to the complexity of this, it has to be 

done in such a way so as not to impact performance. Two separate classes are use by 

HTTPQoS filter to enable such monitoring to take place. These are 

RequestDataMover

 and 

ReplyDataMover

 and they monitor data transfer for HTTP requests and replies to and from a 

target server respectively. The detail of how 

RequestDataMover

 is used by 

HTTPQoS

 is 

worth examining as it highlights the challenges that monitoring performance present and 

how 

HTTPQoS

 overcomes impacting performance. 

a

a

a

a