Caching
Java Agent allocates memory from the Java heap space in the web container to the caches described in this section.
Configuration cache
When the agent starts up in remote configuration mode, it retrieves a copy of the agent profile from AM, and stores it in the cache. The cached information is valid until one of the following events occurs:
-
AM notifies the agent of changes to hot-swappable agent configuration properties. The agent flushes the configuration cache and rereads the agent profile from AM.
-
The agent restarts.
-
The agent rereads the configuration from AM or from local files at the frequency specified by Configuration Reload Interval.
If the reload interval is disabled, and notifications are disabled, the cached configuration remains valid until the agent restarts.
Session cache
After authentication, AM presents the client with a JWT, containing session information. The agent stores part of that session information in the cache.
A session stored in the session cache is valid until one of the following events occur:
-
The session contained in the JWT expires.
-
The client logs out from AM, and session notifications are enabled.
-
The session reaches the expiration time specified by Session Cache TTL.
Policy decision cache
When a client attempts to access a protected resource, the agent checks whether there is a policy decision cached for the resource:
-
If the client session is valid, the agent requests a policy decision from AM and then enforces it.
-
If the client session is not valid, the agent redirects the client to AM for authentication, regardless of why the session is invalid. The agent does not specify the reason why the client needs to authenticate.
After the client authenticates, the agent requests policy decision from AM and enforces it.
Policy decisions are valid in the cache until one of the following events occur:
| Event | What is invalidated? |
|---|---|
Session contained in the JWT expires |
Session and policy decisions related to the session |
Client logs out from AM (and session notifications are enabled) |
Session and policy decisions related to the session |
Policy decision reaches the expiration time specified by Policy Cache TTL |
Policy decision |
Administrator makes a change to policy configuration (and policy notifications are enabled) |
All sessions and all policy decisions |
| A Java Agent that loses connectivity to AM cannot request policy decisions. Therefore, the agent denies access to inbound requests that do not have a policy decision cached until the connection is restored. |
Not-enforced lists hit and miss caches
The first time the agent receives a request for a resource, it matches the request and the client’s IP address against the rules specified in the not-enforced lists.
Java Agent maintains a cache of hit-and-miss for each of the not-enforced lists specified in Not-enforced rules.
To speed up future requests, the agent stores whether the resource hit or missed not-enforced rules in the corresponding caches. Therefore, if a request for the same resource reaches the agent again, the agent replays the result of the rule evaluations stored in the caches, instead of re-evaluating the request.
Entries stored in the hit and miss caches do not expire unless AM notifies the agent about configuration changes in the not-enforced lists.
POST data preservation cache
When POST data preservation is enabled, the agent caches HTML form data submitted as an HTTP POST by unauthenticated clients.
The POST data expires either when the client recovers the information from the cache or after the time interval specified in POST Data Preservation Cache TTL.
For more information, see POST data preservation.
OpenID Connect JWT cache
Decoding JWTs into JSON objects is a CPU-intensive operation. To reduce the amount of processing required on each request, agents cache decoded JWTs.
When an agent receives a request for a resource, it passes the JWT through a fast hashing algorithm that creates a 128-bit hash unique for that JWT. Then the agent determines if the hash is in the JWT cache. One of the following scenarios occur:
-
The hash is in the cache. The agent retrieves the decoded JWT from the cache and continues processing the request.
-
The hash is not in the cache. The agent decodes the JWT and stores it and its hash in the cache. Then it continues processing the request.
JWTs in the cache expire after the time interval specified by JWT Cache TTL.