Changeset 13
- Timestamp:
- 08/04/10 00:53:38 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/web/proxy-reference.html
r1 r13 157 157 <li><a href="#connection-manager/service-map/mapper/allow-services">mapper/allow-services</a></li> 158 158 <li><a href="#connection-manager/service-map/mapper/block-services">mapper/block-services</a></li> 159 <li><a href="#connection-manager/service-map/mapper/dummy-services">mapper/dummy-services</a></li> 159 160 <li><a href="#connection-manager/service-map/mapper/auto-reset-threshold">mapper/auto-reset-threshold</a></li> 160 161 <li><a href="#connection-manager/service-map/mapper/log-missing-sid">mapper/log-missing-sid</a></li> 161 162 <li><a href="#connection-manager/service-map/mapper/broadcast-missing-sid">mapper/broadcast-missing-sid</a></li> 162 <li><a href="#connection-manager/service-map/mapper/unknown-sid">mapper/unknown-sid</a></li>163 163 <li><a href="#connection-manager/service-map/mapper/redundant-forwarding">mapper/redundant-forwarding</a></li> 164 164 <li><a href="#connection-manager/service-map/mapper/retry-lost-services">mapper/retry-lost-services</a></li> … … 474 474 <a name="ca-profiles/profile/max-cw-wait"> 475 475 <div class='indent'>ca-profiles/profile/max-cw-wait</div><br /> 476 This defines the maximum wait time (in seconds) for anything trying to get a CW reply from this profile, before aborting with a timeout (flag T). Under normal circumstances this should be set to the maximum time a client can wait for CW reply without experiencing a freeze (or 1 second above that). Applies to all CWS connectors in this profile, if set here it overrides the global setting in connection-manager.<br /> 476 This defines the maximum wait time (in seconds) for anything trying to get a CW reply from this profile, before aborting with a timeout (flag T). Under normal circumstances this should be set to the maximum time a client can wait for CW reply without experiencing a freeze. Applies to all CWS connectors in this profile, if set here it overrides the global setting in connection-manager.<br /> 477 <strong>NOTE: </strong> When using multi-context connectors (e.g csp-connector or chameleon-connector) the max-cw-wait in effect is the global value, not the per profile one.<br /> 477 478 To determine a reasonable value for max-cw-wait, it is possible to use the test-delay feature in the LoggingPlugin. This can insert an artificial delay into the processing of requests for a specific test-user (source ip address). Increase the delay gradually until freezes occur for the test-user and note the total ecm time in the client logs when this happens, this is your max-cw-wait. Make sure the client ecm timeout is set high enough not to interfere with the result.<br /> 478 479 See <strong>README.Optimization.txt</strong> for more details.<br /> … … 646 647 647 648 <a name="rmi/status-web/csp-connect"> 648 <div class='indent'>rmi/status-web/csp-connect (attributes: enabled, debug )</div><br />649 <div class='indent'>rmi/status-web/csp-connect (attributes: enabled, debug, ignore-cache-requests)</div><br /> 649 650 Allows disabling of csp-connections (csp-connectors from other proxies).<br /> 650 651 Csp-connections are always asynchronous and allow users access to all profiles (that they have access to according to the user-manager) over a single tcp connection. As the httpd is used to receive connections initially, enabling ssl is recommended (without https the credentials are sent in the clear).<br /> … … 652 653 - <strong class='bold'>enabled</strong>: true/false (default: true)<br /> 653 654 - <strong class='bold'>debug</strong>: true/false (default: false). Corresponds to the debug attribute for regular ca-profiles and determines whether to keep the transaction backlog for troubleshooting.<br /> 655 - <strong class='bold'>ignore-cache-requests</strong>: true/false (default: false). Set to true to ignore clients requests for udp cache updates (even when ClusteredCache is in use locally).<br /> 654 656 <br /> 655 657 </a> … … 774 776 <div class='indent'>connection-manager/max-cw-wait</div><br /> 775 777 If a CWS connection is congested or not responding, this defines the maximum wait time (in seconds, default: 9) for anything trying to get a CW reply, before aborting with a timeout (flag T). Under normal circumstances this should be set to the maximum time a client can wait for CW reply without experiencing a freeze (or 1 second above that). This is the default for all CWS connectors in all profiles.<br /> 778 <strong>NOTE: </strong> When using multi-context connectors (e.g csp-connector or chameleon-connector) the max-cw-wait in effect is always this global value, not the per profile one.<br /> 776 779 To determine a reasonable value for max-cw-wait, it is possible to use the test-delay feature in the LoggingPlugin. This can insert an artificial delay into the processing of requests for a specific test-user (source ip address). Increase the delay gradually until freezes occur for the test-user and note the total ecm time in the client logs when this happens, this is your max-cw-wait. Make sure the client ecm timeout is set high enough not to interfere with the result.<br /> 777 780 See <strong>README.Optimization.txt</strong> for more details.<br /> … … 917 920 </a> 918 921 922 <a name="connection-manager/service-map/mapper/dummy-services"> 923 <div class='indent'>connection-manager/service-map/mapper/dummy-services</div><br /> 924 Some clients who are unable to known the real sid (i.e typically hardware solutions) send fixed dummy sids instead of 0. To make sure these aren't treated as real sids by the service mapping, list any such dummy sids here.<br /> 925 <strong>NOTE: </strong> The first sid listed here will also be used when forwarding unknown sid request to connectors, so if you want unknown forwards to keep the sid 0 - set 0 as the first entry in this list.<br /> 926 <br /> 927 Example: <em class='italic'><dummy-services>101 1101</dummy-services></em> <br /> 928 </a> 929 919 930 <a name="connection-manager/service-map/mapper/auto-reset-threshold"> 920 931 <div class='indent'>connection-manager/service-map/mapper/auto-reset-threshold</div><br /> … … 932 943 <div class='indent'>connection-manager/service-map/mapper/broadcast-missing-sid</div><br /> 933 944 true/false (default: false). Enable this to have ecms without sid always forwarded to all non-congested connectors in the profile (as of 0.9.0 causing '2' flags for the affected transactions). Experimental: if there are many clients that cannot send sid, this will significantly increase traffic on the cards. Additionally, even if the broadcasting gets a valid reply the client may still have to perform at least one retry to get it.<br /> 934 <br />935 </a>936 937 <a name="connection-manager/service-map/mapper/unknown-sid">938 <div class='indent'>connection-manager/service-map/mapper/unknown-sid</div><br />939 Defines a special SID that will be sent to servers when SID is 0 (unknown). Client requests for this SID will also be treated as if it was 0. This can be used as a workaround for servers that require a non-zero SID, and for clients that send a fixed special SID instead of 0 when service is unknown (e.g cardlink). Make sure that this isn't set to a real SID that exists in the services file.<br />940 945 <br /> 941 946 </a> … … 949 954 </a> 950 955 951 952 956 <a name="connection-manager/service-map/mapper/retry-lost-services"> 953 957 <div class='indent'>connection-manager/service-map/mapper/retry-lost-services</div><br /> … … 955 959 The status for the service on the particular card in question will be reset with an increasing interval (doubles every time, starting at 5 minutes after it was lost and ending if it hasn't been found after 48 hours). 956 960 Under normal circumstances, you probably want to keep this switched on, for all profiles with service-mapping enabled.<br /> 957 <strong>NOTE: </strong> This mainly helps when there are multiple cards in the profile, if there is only then lost services would be found within minutes when someone tried to watch them, through the auto-reset-threshold.<br />961 <strong>NOTE: </strong> This mainly helps when there are multiple cards in the profile, if there is only one then lost services would be found within minutes when someone tried to watch them, through the auto-reset-threshold.<br /> 958 962 <br /> 959 963 </a> … … 1244 1248 <div class='indent'>cache-handler/cache-config/max-cache-wait</div><br /> 1245 1249 The maximum time (in seconds) that a client can be kept waiting in the cache for a pending request.<br /> 1250 <strong>NOTE: </strong> As of 0.9.0, this can also be configured with a percentage string, e.g "50%" to indicate a max-cache-wait of 50% of the max-cw-wait for the request. This makes more sense when using profiles with radically different max-cw-waits in the same proxy (e.g some with 9 seconds and others with 650 ms).<br /> 1246 1251 See <strong>README.Optimization.txt</strong> for more details.<br /> 1247 1252 <br />
Note:
See TracChangeset
for help on using the changeset viewer.