Request retry
-
Back-end server resets a TCP connection when the appliance sends a request data packet.
-
If back-end server resets a TCP connection on SYN establishment
How request retry works when back-end server resets a TCP connection on receiving a request data packet
-
The process starts by enabling the AppQoE feature on your appliance.
-
When the client sends an HTTP or HTTPS request, the load balancing virtual server sends the request to the back-end server.
-
If the requested service is unavailable, the back-end server resets the TCP connection.
-
If the AppQoE configuration has “retry” enabled with the desired number of retry attempts specified, the load balancing virtual server uses the configured load balancing algorithm to forward the request to the next available application server.
-
After the load balancing virtual server receives the response, the appliance forwards the response to the client.
-
If the available back-end servers are equal or lesser than the retry count and if all the servers send a reset, the appliance would respond a 500 internal server error. Consider a scenario with five available servers and the retry count set as six. If all the five servers reset the connection, then the appliance returns a 500 internal server error to the client.
-
Similarly, if the number of back-end servers is more than the retry count and if the back-end servers reset the connection, the appliance forwards the reset to the client. Consider a scenario with three back-end servers and the retry count set as two. If the three servers reset the connection, then the appliance sends a reset response to the client.
How request retry works when the back-end server resets a TCP connection on SYN establishment
-
The process starts by enabling the AppQoE feature on your appliance.
-
When the client sends an HTTP or HTTPS request, the load balancing virtual server initiates connection to back-end server.
-
If the requested service is unavailable on the TCP SYN establishment, the back-end server resets the TCP connection.
-
If the AppQoE configuration has “retry” enabled with the desired number of retry attempts specified, the load balancing virtual server uses the configured load balancing algorithm to forward the request to the next available application server.
-
After the load balancing virtual server receives the response, the appliance forwards the response to the client.
-
If the available back-end servers are equal or lesser than the retry count and if all the servers send reset, the appliance would respond a 500 internal server error. Consider a scenario with five available servers and the retry count set as six. If all the five servers reset the connection, then the appliance returns a 500 internal server error to the client
-
Similarly, if the number of back-end servers is more than the retry count and if the back-end servers reset the connection on the TCP SYN establishment, the appliance forwards the reset to the client. Consider a scenario with three back-end servers and the retry count set as two. If the three servers reset the connection, then the appliance sends a reset packet to the client.
Configure request retry for GET method
-
Enable AppQoE
-
Add AppQoE action
-
Add AppQoE policy
-
Bind load balancing virtual server to AppQoE policy
Enable AppQoE
enable ns feature appqoe
Add AppQoE action
add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]
add appqoe action reset_action –retryOnReset YES –numretries 5
numretries. Retry count.
Add AppQoE policy
add appqoe policy <name> -rule <expression> -action <string>
add AppQoE policy reset_policy -rule http.req.method.eq(get) -action reset_action
Bind load balancing virtual server to AppQoE policy
bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]
bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1
Configure request retry for POST requests
-
Enable AppQoE
-
Add AppQoE action
-
Add AppQoE policy
-
Bind load balancing virtual server to AppQoE policy
Enable AppQoE
enable ns feature appqoe
Add AppQoE action
add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]
add AppQoE action reset_action –retryOnReset YES –numretries 5
Add AppQoE policy
add appqoe policy <name> -rule <expression> -action <string>
add appqoe policy reset_policy -rule HTTP.REQ.CONTENT_LENGTH.le(2000) -action reset_action
Bind load balancing virtual server to AppQoE policy
bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]
bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1
Configure AppQoE policy for request retry by using the NetScaler GUI
-
Navigate to AppExpert > AppQoE > Policies.
-
In the AppQoE Policies page, click Add.
-
In the Create an AppQoE Policy page, set the following parameters:
-
Name. AppQoE policy name
-
Action. Add or edit an action. To create an action, see Create AppQoE action section.
-
Expression. Select or enter
HTTP.REQ.CONTENT_LENGTH.le (2000)policy expression.
-
-
Click Create and Close.
Configure AppQoE action for request retry balancing by using the NetScaler GUI
-
Navigate to AppExpert > AppQoE > Action.
-
In the AppQoE Actions page, click Add.
-
In the Create AppQoE Action page, set the following parameters for retry on TCP reset: a. Retry on TCP Reset. Select the check box to enable retry action for TCP reset. b. Retry Count. Enter the retry count.
-
Click Create and Close.