The problem with the button cache
is that I misconfigured it.

We started to see people getting logged out of the site unexpectedly while in the middle of a session.

Finally realised that mod_cache is caching the Set-Cookie: headers in the button image responses. The only cookie we would set there is if a request has arrived without an existing session, in which case we set the cookie to indicate our main shop account.

When your cached button image expires, your browser would request the copy cached in apache. Apache would deliver that, along with the Set-Cookie header if one had been stored. Then whoosh - you're back in the shop.

Ooooooh dear.

The fix is easy once you realise that you need it - use

CacheIgnoreHeaders Set-Cookie

to tell mod_cache not to cache the cookie header. That's now in place and is working (I've checked the stored headers and they're clean). Hoping that's the end of it!

T

Labels: caching, config, cookies

- posted by Tim Bruce @ 11:07 PM 0 comments

 
The button cache
Just upgraded the apache installations to support the disk cache. This is part of the plan to move all the sites over to template themes (which is in turn so that we can improve the page structure without having to fix up multiple stylesheets).

One of the features of the template theme engine is that the toolbar buttons are automatically generated on demand. You can select a new colour for the theme and matching buttons will magically appear - no photoshop required.

When we move the main site onto the template theme, that will mean a lot of people will be making a lot of small dynamic requests of the site (paint me a green button) and this could cause some overhead.

Apache now has built-in caching which seems a good fit for this. I've enabled it on the live servers (but just for the button URLs) so that images will be recalculated once every 15 minutes. Seems to be working fine - I can clear the browser cache and request another page, seeing the button image requests logged in apache but not tomcat. Performance seems fine.

T

Labels: caching, config, infrastructure

- posted by Tim Bruce @ 12:20 AM 0 comments

 
Release 6.8.9
New release is live - this adds:

1. Improved file handling (don't retrieve page images from S3 unless we really need them).


2. Eternal disk caching for S3 objects - objects no longer expire automatically.


3. Per-issue cache expiry on demand through a new admin toolbar

The Catapult tool now has support for MD5 generation but it doesn't use this yet - turns out that Amazon's eTag is explictly an MD5 of your content and this does correspond with the digests I'm calculating for the sample files. We can use this when checking for changed content in rsyncs and don't need to store our own MD5 as metadata for the object.

Checked ACLs for the bucket and test objects, those are fine - full_access for the owner and nothing more.

Finally to enable logging, then upload a live title and switch it over.

T

Labels: caching, release, s3

- posted by Tim Bruce @ 5:21 PM 0 comments

 
Caching nulls
Some of our pages don't have associated links or wordmaps (full-page images, for example).

Our new S3StorageManager used to return nulls to indicate that there was no such information - this has the drawback that while EHCache can store nulls as cache values, they can't be persisted to disk (as null is not Serializable). So after every restart the service would have to contact S3 again to establish that there was no wordmap for a particular page.

We're now returning empty byte arrays instead - these have the same meaning to the consumer of the information and can be cached between application shutdowns. Speed, speed...

T

Labels: caching, s3

- posted by Tim Bruce @ 12:31 PM 0 comments

 
EHCache
is a fine, fine thing.

S3StorageManager is now caching the retrieved objects in a persistent disk cache. Next to bring LocalStorageManager up to speed, simplify the Highlighter and make a release.

The Shibboleth project is almost done. Our local federation gave the all clear last night, so we're now in their metadata. Did some initial testing with a real IdP today which worked initially but then broke - checked with the IdP that their metadata is up to date, as someone else had a similar problem for which stale metadata was the culprit. I must have tweaked something unfortunate. More testing on the way.

T

Labels: caching, s3, shibboleth

- posted by Tim Bruce @ 6:34 PM 0 comments

 
Persistent caches in Spring
The S3StorageManager is now picking up page images, word maps and links from S3 - woohoo! The next step is to enable caching so that it doesn't have to fetch a page image multiple times. The web servers will have plenty of free disk space so I'd like to use that to cache the objects from S3.

I had planned to use the AOP caching mechanism in Spring to take care of this automatically, storing objects in a persistent EHCache on the disk. Everything's configured and I can see the images getting pushed into the persistent cache, but they're never found again once you restart the application - so we'd get the benefits of caching while the app is running, but a site update or restart would mean we'd have to rebuild the cache from scratch.

A bit of poking around reveals that the CacheInterceptor is prepending the oject id of the target object to the cache key. I can see why that's a good idea (you probably do want to partition the method results cache contents by target most of the time), but it means that results cached from one object won't be used once that particular instance object's been replaced. In our case the target is a singleton anyway so we don't get any benefit.

I think the best solution might be for our S3StorageManager to manage its own cache explicitly. Off to check the EHCache documentation...

T

Labels: caching, s3, spring

- posted by Tim Bruce @ 5:29 PM 0 comments