Ticket #478 (closed Enhancement: fixed)

Opened 7 years ago

Last modified 7 years ago

Exploit the Browser Cache

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.2
Component: DeepaMehta Standard Distribution Version: 4.1
Keywords: Cc: dgf, Malte
Complexity: 8 Area:
Module:

Description

To reduce network round-trips the Webclient should maintain an entity cache for topics and associations. The cache could be validated by the entities modified timestamps (see #386). To do so, the Webclient must set the If-Modified-Since header in at least two GET requests:

/core/topic/{id}
/core/association/{id}

The server in turn must compare the request's timestamp to the one stored in the DB and must respond with 304 (Not Modified) when indicated.

An ETag-based approach could also be considered.

The timestamps (resp. Etags) would also serve as the basis for the detection of edit conflicts (see #479).

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by jri

New Core Event PRE_PROCESS_REQUEST (#480, #478).

Fired before a request is processed. That is *before* a possible resource method is invoked.
This allows a plugin e.g. to abort request processing in case a pre-condition is not met (as stated e.g. by the If-Modified-Since or If-Unmodified-Since headers).

New listener interface:

de.deepamehta.core.service.event.PreProcessRequestListener?

Listener method:

void preProcessRequest(ContainerRequest? request)

Note: ContainerRequest? is a Jersey-specific class
(com.sun.jersey.spi.container.ContainerRequest?).
We should remove the Jersey dependency and move to JAX-RS 2.0 instead.

Close ticket 480.
See ticket 478.

Changeset: 0d1cf5baded3320d0520e32fd5cc1674ce77eb27

comment:3 Changed 7 years ago by jri

New plugin: DeepaMehta 4 Caching (#478).

If a If-Modified-Since header is present in a GET request a 304 (Not Modified) response is possibly send.
In this case the topic/association is not fecthed from the DB. Only the timestamp is.

See ticket 478.

Changeset: 372907375787b099f0fceca1dd57242864a8d57d

comment:4 Changed 7 years ago by jri

Add 2 new plugins to reactor build (#386, #478).

DeepaMehta 4 Time
DeepaMehta 4 Caching

See ticket 386.
See ticket 478.

Changeset: b9c5fa2584ff000a6560df1e92ce97b0312d2e27

comment:5 Changed 7 years ago by jri

Caching plugin: set Cache-Control header (#478).

If the response contains a single DeepaMehtaObject? the response's freshness lifetime is set to zero. That is the Last-Modified response header is set to max-age=0. This enforces the browser to revalidate its cache for every request (typically by sending a conditional GET request).

See ticket 478.

Changeset: 41c1f0bc0f1d89855494e355fc033ed591b8a188

comment:6 Changed 7 years ago by jri

There is a bug in the Webclient module: see #488

comment:7 Changed 7 years ago by jri

Caching: fix conditional PUT request (#386, #478).

Topics/associations contained in a Directives object are enriched with their modification timestamps.
As a consequence the Caching module uses the up-to-date modification timestamp when constructing a subsequent PUT request.

See ticket 386.
See ticket 478.

Changeset: 4528ffa5017160f17e675cfea16545e563027081

comment:8 Changed 7 years ago by jri

There is a bug: once the user's login status changes the browser cache still holds the old permissions that are cached along with the topics/associations.
As a consequence e.g. after login a topic is not editable as long as the browser cache is reset (resp. reload is pressed several times).

Solution: the Access Control module must *not* deliver the permissions along with the topic/association (in the composite value). Instead the Webclient must request the permissions separately via the Access Control service.
To reduce requests the Access Control module could maintain its own cache for the permission information, and invalidate it once the user's login status changes.

UPDATE: this issue got its own ticket (#489).

Last edited 7 years ago by jri (previous) (diff)

comment:9 Changed 7 years ago by jri

Access Control: fix permission cache (#489, #478).

The Access Control module does *not* deliver the permissions along with the topic/association (in the composite value). Instead the Webclient requests the permissions separately via the Access Control service.

To reduce the number of requests the Access Control module maintains its own client-side cache for the permission information, and invalidates it once the user's login status changes.

This fixes the bug of stale permissions (due to browser caching) once the user's login status changes.

=> For the first time since introduction of timestamps, edit conflict detection, and browser caching DM should be in a good shape now. Please give it a try and report any problems.

Access Control API has 1 new method:

  • Server-side: Permissions getAssociationPermissions(long assocId)
  • RESTful: GET /accesscontrol/association/{id}
  • Cliet-side: dm4c.restc.get_association_permissions(assoc_id)

Close ticket 489.
See ticket 478.

Changeset: b9170f2d85ab6dcc108af1e2497dd6c94b869af4

comment:10 Changed 7 years ago by jri

  • Summary changed from HTTP Cache to Exploit the Browser Cache

comment:11 Changed 7 years ago by jri

Time and Caching fixes (#386, #478, #479).

FIXES

  • Browser caching is enabled also for topics/associations which have no timestamp. 0 assumed as default (Jan 1, 1970).
  • Edit conflict detection works also for topics/associations which have no timestamp.

CHANGES

Time plugin:

  • for topics/associations send to the client their creation timestamp is available in the composite value as well (besides the modification timestamp).
  • the time API's timestamp getter methods return 0 as default in case no timestamp is stored (before -1 has been returned).
  • the Last-Modified response header is also set for a default timestamp value (0).

Caching plugin:

  • a request's precondiction is also checked for a default timestamp value (0).

See #386.
See #478.
See #479.

Changeset: 1b5bbdb7c6b963915168f5a7c69e6ccb8a13d427

comment:12 Changed 7 years ago by Malte

Please consider also setting the max-age header for all static resources (scripts, images, stylesheets) to some value so we can exploit the browser cache even more optimal.

comment:13 Changed 7 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

Thanks, Malte, for the hint. I created a separate ticket for that: #501.

This ticket is regarded as complete now.

Note: See TracTickets for help on using tickets.