Page Comparison

The Throttle Mediator can be used for rate-limiting as well as concurrency-based limiting. A WS-Policy dictates the throttling configuration and may be specified inline or loaded from the registry. The Throttle Mediator could be added in the request path for rate limiting and concurrent access limitation. When using for concurrent access limitation, the same Throttle Mediator id must be triggered on the response flow so that completed responses are deducted from the available limit. (i.e. two instances of the throttle mediator with the same id attribute in the request and response flows). The onReject and onAccept sequence references or inline sequences define how accepted and rejected messages are to be handledto restrict access to services. This is useful when services used at the enterprise level and it is required to avoid heavy loads that can cause performance issues in the system. It can also be used when you want to avoid certain user groups (i.e. IP addresses and domains) accessing your system. The Throttle mediator defines a throttle group which includes the following.

• A throttle policy which defines the extent to which, individuals and groups of IP addresses/domains should be allowed to access the service.
• A mediation sequence to handle requests that were accepted based on the throttle policy.
• A mediation sequence to handle requests that were rejected based on the throttle policy.

...

...

Syntax

<throttle [onReject="string"] [onAccept="string"] id="string">
    (<policy key="string"/> | <policy>..</policy>)
    <onReject>..</onReject>?
    <onAccept>..</onAccept>?
</throttle>

...

UI Configuration

The UI of the Throttle mediator are divided into following sections. Before you edit these sections, enter an ID for the Throttle group in the Throttle Group ID parameter.

Throttle Policy 

Anchor
Throttle Policy Throttle Policy

This section is used to specify the throttle policy that should apply to the requests passing through the Throttle mediator. A throttle policy has a number of entries defining the extent to which, an individual or a group of IP addresses/domains should be allowed to access the service.

The parameters available to configure the Throttle mediator to be configured in this section are as follows.

The parameters available in the Mediator Throttling Configuration dialog box to configure the Throttling policy are as follows.

...

Throttle Mediator Options:

• Throttle Group ID - The id for the throttle group.

  Info
  title Note
  You would have to throttle mediator configuration in request and response paths with the same group id.

• Throttle Referring Policy - The policy for the throttling. You can specify it inline or refer from Configuration Registry or Governance Registry.
• On Acceptance Referring Sequence - The sequence to act on acceptance. You can specify it inline or refer from Configuration Registry or Governance Registry.
• On Rejection Referring Sequence - The sequence to act on rejection. You can specify it inline or refer from Configuration Registry or Governance Registry.

On Acceptance

This section is used to specify the mediation sequence that should be applied when a request is accepted based on the throttle policy defined for the Throttle mediator. The parameters available to be configured in this section are as follows.

On Rejection

This section is used to specify the mediation sequence that should be applied when a request is rejected based on the throttle policy defined for the Throttle mediator. The parameters available to be configured in this section are as follows.

Example

In this example,  the Throttle Mediator inside the In Mediator. Therefore, all request messages directed to the main sequence will be subjected to throttling. The Throttle Mediator has policy, onAccept and onReject tags at top level. The policy tag specifies the throttling policy for throttling messages. This sample policy only contains a component called MaximumConcurrentAccess. This indicates the maximum number of concurrent requests that can pass through Synapse on a single unit of time, and this value applies to all the IP addresses and domains.

The onAccept sequence includes a Log mediator with a custom log to log the accepted requests.Then the Send mediator sends these requests to http://localhost:9000/services/SimpleStockQuoteService.

The OnReject sequence too includes a Log mediator with a custom log to log the rejected requests. Then a Fault mediator is used to convert the message into a fault message. The fault message is then returned to the client as a response using the Respond mediator, and then dropped using the Drop mediator.

<in>
    <throttle id="A">
        <policy>
            <!-- define throttle policy -->
            <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
                        xmlns:throttle="http://www.wso2.org/products/wso2commons/throttle">
                <throttle:ThrottleAssertion>
                    <throttle:MaximumConcurrentAccess>10</throttle:MaximumConcurrentAccess>
                </throttle:ThrottleAssertion>
            </wsp:Policy>
        </policy>
        <onAccept>
            <log level="custom">
                <property name="text" value="**Access Accept**"/>
            </log>
            <send>
                <endpoint>
                    <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
                </endpoint>
            </send>
        </onAccept>
        <onReject>
            <log level="custom">
                <property name="text" value="**Access Denied**"/>
            </log>
            <makefault>
                <code value="tns:Receiver"
                      xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>
                <reason value="**Access Denied**"/>
            </makefault>
            <property name="RESPONSE" value="true"/>
            <header name="To" action="remove"<respond/>
            <send/>
            <drop/>
        </onReject>
    </throttle>
</in>

...