Skip to content

Overview

Concepts and Principles

Development

Overview

IDEs

API Explorer

Releases

Release Notes

TORO Integrate

Coder Studio

Coder Cloud

Bug Reports

Search

Caching

Introduction

The examples package also provides an example service that demonstrates how caching could be done via one-liners from the CacheMethods class.

The service CachedWeatherResponseDemo.gloop caches the current weather forecast provided by a mock weather service1, then deletes the entry 10 seconds after its creation. This service has been exposed as a REST API and can be accessed through the following URL2:

1
<host>:<port>/api/cached/mock-api/getCurrentWeather/{city}/{countryCode}

Related articles

Please see the following articles for more information:

Try It!

Under the Coder Navigator, expand the examples package entry and navigate to the code folder. Afterwards, look for the cachingDemo package. This package contains the files and/or directories shown below:

1
2
3
4
5
6
7
8
examples
├── ...
└── code
    └── ...
    └── cachingDemo
        ├── api
        │   └── CachedMockedWeatherApi.api
        └── CachedWeatherResponseDemo.gloop

Under this package is the CachedWeatherResponseDemo.gloop service which demonstrates cache usage and the cachingDemo.api.CachedMockedWeatherApi.api file, which exposes the CachedWeatherResponseDemo.gloop service as a REST endpoint.

By running the service multiple times3, you will notice that during a certain amount of time, the response the service gives will be the same. When the cache expires, it will respond with a new set of data and will be returning the same data for a specific amount of time again.

Check it out!

You will find a more detailed explanation about this example you if check the Comments tab (found at the right side of the Coder Studio UI) of CachedWeatherResponseDemo.gloop. Each step in the service is also decorated with comments to better explain the implementation.

How It Works...

Each Integrate Package contains its own CacheManager. The examples package has one already set up and its configuration is defined in conf/caches.conf.

1
2
3
4
5
6
examples
├── ...
├── code
└── conf
    ├── caches.conf
    └── ...

Inside the caches.conf file, we have a CacheManager configured called cachedWeatherResponse that we use to cache the response from our exposed REST API.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
cachedWeatherResponse {
    provider = "guava"  // (required)
    // Specifies that each entry should be automatically removed from the cache once a fixed duration has elapsed
    // after the entry's creation, or the most recent replacement of its value.
    expireAfterWrite = 10s  // (optional) <long>ns | us | ms | s | m | h | d default is ms

    // Each entry should be automatically removed from the cache once a fixed duration has elapsed
    // after the entry's creation, the most recent replacement of its value, or its last access.
    //expireAfterAccess = 5s  // (optional) <long>ns | us | ms | s | m | h | d default is ms
}

If you want to set up your own CacheManager, simply create a caches.conf file for your package and define your CacheManager there. You can define multiple CacheManagers in the caches.conf file.

TORO Integrate currently supports Ehcache and Guava. Below is a sample configuration you can use to set up your own CacheManager:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
myCache1 {
     provider = "guava"                 // (required)
     expireAfterWrite = 1h    
     expireAfterAccess = 15m

     heap = 3200
 }
 myCache2 {
    provider = "ehcache"                // (required)
    expireAfterWrite = 1h
    expireAfterAccess = 15m

    key {
       type = "java.lang.String"      // (default)
       serializer = ""
    }

    value {
       type = "java.io.Serializable"  // (default)
       serializer = ""
    }

    heap = 3200                 // 3200 entries; may append units (MB, etc)                      
    offHeap = 5MB               
    disk = 10MB                     
    diskStore = /tmp/ehcache    // required if using 'disk' persistence
}

The format above uses HOCON - a superset of JSON. At minimum, a cache is configurable with just:

1
2
3
4
5
6
cacheName {
    provider = guava | ehcache
    heap = `long`

    expireAfter* =             // if not provided, the cache is like noop
}

  1. based on a city-country combination 

  2. <host> and <port> must be substituted according to your server's configurations 

  3. You can do this easily via REST API calls to /cached/mock-api/getCurrentWeather/{city}/{country}