Can we configure LISA for time out and system down scenario's ???

[VineetTevetiya]

#servicevirtualization #LISA

[Legacy User]

Take a look at the Failover Execution Mode described here: Execution Mode - DevTest Solutions - 10.0 - CA Technologies Documentation to see if it achieves your requirement.

 

With regard to HTTP timeouts, the Live Invocation Step has to wait for the HTTP timeout between the virtual service and the live system endpoint to occur in order to trap the timeout. There is no step-level timeout setting that you can specify in the Live Invocation Step.   

 

Some discussion of property values is provided here: Local Properties File - DevTest Solutions - 10.0 - CA Technologies Documentation  

 

This section in the local.properties files allows one to globally override HTTP timeout properties for all services.

## ==============================================
## HTTP Timeouts (in milliseconds)
## The default values have been change to 15000 for the connection timeout
## and 180000 for the socket timeout. If you would like to extend the timeout
## to wait indefinitely, set the values to 0.
## ==============================================
#lisa.http.timeout.connection=0
#lisa.http.timeout.socket=0

[VineetTevetiya]

Hi Joel,
Thanks for the suggestion. While going through forums i found think time, i think it will work for me.
But i am still in dark whether i can configure system down scenario for my web service call using CA LISA ?

[Legacy User]

My apologies. I was thinking of the inverse scenario where the live system is down and the virtual service should attempt to respond in its place.

 

Setting Think Time can help you slow responses down, but may not necessarily create timeouts on the service consumer end.

 

One method of simulating an HTTP timeout (i.e., where the virtual service provides no response to a given request), I usually set up the VSI such that the response contains a non-standard response body that can be trapped in the VSM. When the VSM sees this value in the response body, it can perform some specified behavior.  

 

Consider the following example.

- Suppose we set up the VSI to match on a specific scenario (input arg values equal to something) so that the service only provides a "no response" when we have a specific set of input criteria

- For this specific match, I might replace the real response body with a string value of "404" (or any value you choose) without the quotes.

- In the VSM's VSI Selection Step, I might add a scripted assertion that examines the lisa_vse_response body for the value and perform some expected behavior.  For example:

if ( "404".equals( lisa_vse_response.get(0).getBodyAsString() ) )

    return true;

else

    return false;

- For the branching on the Assertion, if the response is true, branch to Listen step. If the response is false, continue on the Responder step so a response is sent. The branch to Listen causes the VSM to never respond for this specific transaction to the consumer. The result on the consumer side is an HTTP timeout.

 

For system unreachable (i.e., connection refused errors), stop the virtual service so that nothing is listening on the assigned (listen on) port. There's not much other way of causing a system unreachable error response since this is handled by the transport layer.

[VineetTevetiya]

Hi Joel,
Thanks for the response. I have tried myself by sending 404 response but that didn't work out because the status code in meta data of response was set as 200, so even though we were givng response as 404 we were sending the success code for web service call.
Also can you guide me how to stop the webservice. I have achieved the system down scenario, but this might be helpful in future. Also can I stop the service for a particular request.

[Legacy User]

I used '404' in the example above, however, that is not an HTTP Response Code. It is just a value in the response body.

 

The example shows a scenario where the virtual service never responds at all to the consumer for a specific transaction. If you configured the service as above and your consumer received a response, there is an error somewhere. The service should not have sent a response to the consumer if the VSI/VSM both worked properly. This means the HTTP 200 status response in Meta Data would not be processed by the consumer. 

 

Actions against the virtual service can be taken via the Portal --> Monitor --> VSE --> your VS.

Monitor Virtual Services - DevTest Solutions - 10.1 - CA Technologies Documentation  

[Legacy User]

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.

Attachment(s)

Example_No_Response_Service.zip   128 KB 1 version

[norre01]

Vineet,

Did Joel's recommendations help you out with this issue?

Regards,

Reid