Service Caching to Avoid Duplicate Requests Follow

Systems having frequent connection losses will cause in most browsers (including chrome) an automatic refries for sending failed requests. This will cause identical requests to be sent again and again to the ServiceManager while former retires are still waiting to be processed.  Besides the performance issue it may cause, in some cases, a disruption of the data or system errors.

ServiceManager offers a caching feature to provide a solution for such cases of duplicate requests.

With this feature turned on, service calls & responses are cached on the server side for a predefined amount of time. Any subsequent calls that correspond to the same request will retrieve the same response as the original call, without running the service again.

This feature is supported only for REST requests (SOAP requests don't follow this mechanism).

Enabling cache

Caching is disabled by default, to enable it you must set the following properties in Admin > System Properties:

• SERVICE_CACHE_SIZE - maximum number of responses in cache.
• SERVICE_CACHE_VALIDITY_MINUTES - time in minutes since service is first called, until evicting its cached response (recommended: 10)

Setting any of these properties to zero will deactivate the cache.

Sending cacheable requests

Once cache is enabled in System Properties, clients willing to use the cache mechanism should provide a dedicated query / post parameter when performing service calls:

• requestId - unique string for identifying the request in the client side (usually a currentMilliseconds timestamp is sufficient - new Date().getTime()). 

Example

1. Service Manager is configured with:
   SERVICE_CACHE_SIZE = 1000
   SERVICE_CACHE_VALIDITY_MINUTES = 10
   
   
2. Client calls the "y_Login" service: 
   http://localhost:8080/ServiceManager/Macro/ExecMacro/y_Login?requestId=1547055508164
   
   
3. Request reaches the ServiceManager server and service starts execution.

At this point, and for the next 10 minutes - 

• If the network connection between the client and the ServiceManager is lost, the client may still access the response when it's back.
• If the client calls y_Login service again with the same requestId=1547055508164:
  • If the original request haven't finished yet, the new call will block and wait for the original response (up to the configured service timeout).
  • If finished, the original response will be returned immediately without executing any logic.

After 10 minutes since the original call started executing, the cached response will be deleted, and any calls will lead to standard service execution.

Debugging

Cache statistics will be logged to the LogViewer (Admin > View Log) every time the System Properties are updated.
Statistics include hit count, eviction count, and entries present at the cache at that time.
Stats will be logged in TRACE level - make sure your log displays TRACE level if you wish to view this information.

Saving the System Properties restarts the ServiceManager and resets the Service Cache as well - all entries will be evicted.