The attached 9.5.1 project contains a sample VSM / VSI that causes an HTTP timeout (i.e., no response) to occur. This example can be run in ITR mode.
You will need some type of client to send a request (SoapUI, Postman, etc.).
Sample requests reside in the project's data directory:
- Valid_Request.xml contains a sample request body that can be posted to the service. This example assumes the service is running on localhost and listening on port 8050.
- Cause_No_Responset.xml contains a sample request body that, when posted to the service, causes a timeout.
For demonstration purposes, the VSI has two payload operations - the first operation having on one (1) signature argument sends a valid response, and the second operation having two (2) signature arguments contains the "404" in the response body that causes the no response (HTTP Timeout). This set up is not required. It just keeps the good and bad separated so folks can easily see the differences.
As seen in the ITR snapshot, below, after executing the VS Image Selection Step, the service branches to the Listen step -- in this case, no response is sent and the consumer will wait for its HTTP timeout to occur.
Open the VSM and double click on the Assert Do Not Respond assertion to view the code that causes the branch to the Listen Step resulting in the service not sending a response to the consumer. Look in the VSI and you can see the "404" in the body. The Virtual HTTPs Listener step is highlighted in RED because ITR execution was stopped as soon as the branch to Listen step occurred. The key is that the Virtual HTTPS Responder step never fires.
NOTE: This negative or edge testing technique is handy during performance testing. Consider for example, that we want to ensure that the consumer application handles timeout scenarios properly -- which may be difficult to simulate in a real production application. This service design achieves that by allowing developers to examine how the consumer application behaves when a high number of connections are held open due to the non-response.
When considering entropy or lack of order scenarios, one might implement a broader use case by altering the code that determines whether or not to cause a timeout. For example, rather than a response body of "404" indicating a no-response, a Config property might contain a percentage value that describes things like "we want x% of all incoming requests to cause a timeout". Deploy the service with a given Config (i.e., property value of 3%, 5%, 20%, etc.). Extend the service to create and examine a random value between 0 and 100. If the value is "inside" the % specified by the property, cause a timeout. If the random value is outside the %, send the VSI's response.