WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Endpoint
Name:PiggybackThrottle
Description:Throttle that piggybacks the work performed by identical concurrent requests to reduce processing
Id:mod.architecture.PiggybackThrottle
Category:transparent overlay

PiggybackThrottle is a transparent overlay. You must instantiate an instance of the overlay from its prototype, this will create a new instance within your application space.

Parameters

The mod.architecture.PiggybackThrottle prototype has the following initialisation parameters:

NameRulesTypingDefaultDescription
spaceMandatorySpace(none)
A nested space definition which the overlay will delegate all requests in to.

Here is an auto-generated example of how to instantiate an instance of PiggybackThrottle:

<overlay>
  <prototype>mod.architecture.PiggybackThrottle</prototype>
  <space>
    < !--wrapped space...-->
  </space>
</overlay>
Import Requirements

To use PiggybackThrottle transparent overlay you must import the module urn:com:ten60:netkernel:mod:architecture:

<import>
  <uri>urn:com:ten60:netkernel:mod:architecture</uri>
</import>

The design intent of the PiggybackThrottle is to eliminate redundant computation when one or more identical requests are issued to the same resource at the same time. Typically this is only useful for idempotent requests such as SOURCE/EXISTS requests that return the state of a resource without side-effect.

This situation can commonly happen at system startup or after invalidation of an expensive resource. It happens because until a representation has been fully computed and cached identical duplicate requests cannot retrieve the representation from cache and will cause a parallel identical computation to be initiated.

Operation

This throttle acts as multiple parallel blocking gates, one for each unique resource request. If there is no concurrent identical request to the request being processed then this request is passed through the throttle transparently. However if there are earlier concurrent identical requests that are still being processed then the current request will be blocked until the response from the earlier request is received. At this time all blocked identical requests will receive the response from the first request and will therefore not be issued down into the inner space of the throttle overlay.

Identical requests are determined by keying the request on the following fields:

  • resource identifier
  • request verb
  • requested representation