The factory commands are not fully documented as generaly they are settings that should not be altered, such as the size of buffers and other system variables. There are some which are which are referenced in the manuals and AppNotes,
As the DX proxies the cluster connections it handles the client-side seperately from the server-side connections, so if the client uses a HTTP header of Connection: Keep-Alive the DX will allow the client connection to be maintained, so it could be re-used by the client without having to establish a new connection. Why do you need the client to receive the FIN from the server?
If you use client keep-alives (factory kac enabled) then you can close client connections using ' factory kac cc [rv0|rv1]' where rv0 is for HTTP/1.0 clients and rv1 is for HTTP/1.1 clients. This can be applied at the server or cluster level. The default value is 0, which means to never close the client connections.
% sh server factory kac cc rv0 Factory kac cc rv0: 0 % sh server factory kac cc rv1 Factory kac cc rv1: 0
% sh cluster 1 factory kac cc rv0 factory kac rv0: global % sh cluster 1 factory kac cc rv1 factory kac rv1: global
The value can be 0-3, which stand for:
The description I have for factory a scr is 'Server connection reset', so I assume this makes the DX send a RST to the server when it closes a connection, rather than the graceful close with FINs.
You can adjust the TCP keep-alive timers with 't ckat' and 't tkat', which refer to client and target keep-alives respectivelty. These can be set globally or at the cluster or forwarder level, with the value between 1 and 36000 seconds. e.g.
% set cluster 1 factory t ckat 99999999999999999999 value must be between 1 and 36000
Hi Matt, the problem is that the client keeps the connection open and it's dropped silently on one of our devices between the client and the DX (e.g. office proxy, FW, loadbalancer). So if the client does another request after e.g. 5 minutes he gets an error:
Network Error (tcp_error)
A communication error occurred: "" The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
After pressing f5 to establish a new session it works fine. Therefore we would like to close the session from the compressor side.
I'm just testing with the customer and after disabling the keepalives it seems that the problem is gone. Need to perform another network trace to understand why.