Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Caching functionality is provided by the Caching feature, which is currently bundled in the Service Management feature in the WSO2 feature repository. The caching feature provides a tool that is used to cache Caching stores responses for requests that are identical , thereby enhancing and therefore enhances the response time times for subsequent requests. When caching is enabled, subsequent requests with the same hash value as the previous request whose response was cached, will be served with the same cached response.

Caching can be enabled at three levels as follows. In all 3 levels, specific caching configuration steps are the same from step 4 onwards in the service-level caching configuration section described below.:

  • Global-Level - Global level engagement of caching will apply caching for all the messages coming into  : Caches responses from all the services in a hosted server instance. All the responses from all the services will be cached. For information on how to access global-level caching, refer to section Axis2 Modules -> , see Configuring the ' wso2caching ' Module.
  • Service-Level - If caching is engaged at service level, all the responses that are generated by all the operations of that particular service will be cached.Response Caching  
  • Operation-Level - If engaged at operation level, only those  : Caches only responses from that a particular operation of a given service will be cached. For information on how to access operation-level caching configuration windows, refer to section , see  Operation Management.
  • Service-Level
Response Caching AnchorService-Level Response CachingService-Level Response CachingFollow the instructions
  •  : Caches only the responses generated by the operations of a particular service as described below.
Note

It is advisable to consider the dynamic nature of your services before enabling caching globally. For example, an operation that generates random numbers might not benefit by caching previous responses, because it generates a unique response for each invocation anyway.

Service-level response caching

Table of Contents
maxLevel4
minLevel4

Using the management console

Follow the steps below to add response caching to a service using the servicemanagement console.  1.

  1. Log
on
  1. in to the
product's
  1. management console and
select "List" under "Services."

Image Removed

2. The "Deployed Services" page appears. Click on the service, for
  1. select Services > List under the Main menu.  
  2. From the Deployed Services page that appears, click the service to which you want to
activate
  1. enable caching.
For example,

Image Removed

3. The "Service Dashboard" page appears. Click "Response Caching" in the "Quality of Service Configuration" panel.

Image Removed

Anchor444. The "Caching Configuration for Service" page appears. In the "Enable Caching" list, click "Yes."

Image Removed

5. The last saved configuration or the default configuration (if it is the first time) for caching will be displayed.

Image Removed

Fields in Wizard:

Hash Generator -
  1.   
  2. The service's dashboard opens. Click Response Caching from the Quality of Service Configuration panel. Image Added  
  3. Enable caching to the service by selecting Yes. Image Added  
  4. Change the default caching configuration settings as you need. Image Added

    The options of the above window are as follows:

    • Hash Generator  : Specifies the fully qualified class name of the hash value generator. This class implements
the
    • the org.wso2.caching.digest.DigestGenerator
interface
    •  interface. It is responsible for generating a
"
    • Hash
"
    • value for each request message, so that a matching response message can be located from the cache. The default
is
    • is org.wso2.caching.digest.DOMHASHGenerator. You can implement your own
"
    • Hash
"
    • generator class and use it with the WSO2
product
    • products. However, the default hash generator
should be good
    • is enough for general use.
    • Timeout
-
    •  : Shows the time period, in milliseconds,
that
    • during which a cached response is kept in memory. The counting starts from the time the first request is received. Any request
,
    • received after the counter has started and is within the Timeout period
,
    • is served with the response cached upon receiving the first request. Once the Timeout expires, the cache will be updated with the response generated for the first request that was received after the expiry.
    • Maximum Cache Size
-
    •  : Holds the maximum number of response messages that
will be
    • are cached. If the maximum number of responses are already cached and none of the cached responses' Timeouts have expired, then future responses are not cached until this memory is free enough to accommodate
caching
    • a new response.
    • Maximum Message Size
-
    •   : Shows the response message that is cached. Response messages larger than this (in size) are not cached. Caching is an expensive operation for larger messages, especially given the amount of memory required. Therefore, this value should be set considering the performance and resource trade-offs.
  1. Click Finish after the config is done.

    The rest of the function of buttons on this window are as follows:

    • Finish 
Info
titleNote

It is advised that you consider the dynamic nature of your services before enabling caching globally. For example, an operation that is supposed to generate random numbers would not benefit from caching previous responses, because it is supposed to generate a unique response for each invocation.

6. Click "Finish." Caching will be engaged for that particular service.

Functions of Buttons:

  • Finish - Click "Finish" to submit the current data. When finished, your throttle configuration will be applied and the page will be redirected to the previous page.
  • Reset - Click "Reset" to load the last submitted configuration.
  • Default - Click "Default" to load the default throttle configuration. If you want to submit those data, you have to click "Finish."
  • Clear - Click "Clear" to clear all the text boxes in the user interface.
  • Cancel - Click "Cancel" to go to the "Service Dashboard" page.
Excerpt
hiddentrue
Response Caching configuration in WSO2 Application Server
    • : Submits the current data
    • Reset  : Loads the last submitted configuration
    • Default  : Loads the default RM configuration. (Click Finish to submit)
    • Clear  : Clears he text boxes
    • Cancel  : Goes back to the service dashboard

Without using the management console

You can configure service-level caching directly in the .dbs file of a data service or by writing a separate configuration file and referring to it from the .dbs files. This allows you to configure caching without going through the management console.

Each data service is deployed as an axis2 service. Therefore, you can use the services.xml file, which is typically used to configure axis2 service related parameters, for data services as well with slight modifications. That is, if the name of your data service is TestDS, you must name your services.xml file as TestDS_services.xml and place it in the data services deployment directory. (e.g., <PRODUCT_HOME>/repository/deployment/server/dataservices). Then, include a caching policy with your own values as parameters inside the configuration file mentioned above.

Shown below is a sample services.xml file:

Code Block
languagehtml/xml
<serviceGroup>
    <service name="TestDS">
        <!--parameter name="ServiceObjectSupplier">org.apache.axis2.engine.DefaultObjectSupplier</parameter-->
    <Description>Enabling caching through sevices.xml</Description>

    <operation name="op1">
        <messageReceiver class="org.wso2.carbon.dataservices.core.DBInOutMessageReceiver"/>
    <module ref="wso2caching"/>
        <wsp:Policy
            wsu:Id="WSO2CachingPolicy"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsch:CachingAssertion xmlns:wsch="http://www.wso2.org/ns/2007/06/commons/caching">
        <wsp:Policy>
            <wsp:All>
            <wsch:XMLIdentifier>org.wso2.caching.digest.DOMHASHGenerator</wsch:XMLIdentifier>
            <wsch:ExpireTime>70000</wsch:ExpireTime>
            <wsch:MaxCacheSize>1000</wsch:MaxCacheSize>
            <wsch:MaxMessageSize>1000</wsch:MaxMessageSize>
            </wsp:All>
        </wsp:Policy>
        </wsch:CachingAssertion>
        </wsp:Policy>
    </operation>

    <operation name="op2">
        <messageReceiver class="org.wso2.carbon.dataservices.core.DBInOutMessageReceiver"/>
    <module ref="wso2caching"/>
        <wsp:Policy
            wsu:Id="WSO2CachingPolicy"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsch:CachingAssertion xmlns:wsch="http://www.wso2.org/ns/2007/06/commons/caching">
        <wsp:Policy>
            <wsp:All>
            <wsch:XMLIdentifier>org.wso2.caching.digest.DOMHASHGenerator</wsch:XMLIdentifier>
            <wsch:ExpireTime>600000</wsch:ExpireTime>
            <wsch:MaxCacheSize>1000</wsch:MaxCacheSize>
            <wsch:MaxMessageSize>1000</wsch:MaxMessageSize>
            </wsp:All>
        </wsp:Policy>
        </wsch:CachingAssertion>
        </wsp:Policy>
    </operation>
        <operation name="op3">
        </operation>
    </service>
</serviceGroup> 
After placing the XML file (e.g., TestDS_services.xml) in the deployment directory, comment out the following entry from <PRODUCT_HOME>/repository/conf/axis2.xml file.
Code Block
languagehtml/xml
<listener class="org.wso2.carbon.core.deployment.DeploymentInterceptor"> 

Restart the server for the changes to apply.