In case you can't guess from the title of this post, this is the second in a series of posts related to my experiences developing and tuning an auto-refreshing cache.
Challenges for pre-loading
The particular caching software which we applied for this project has a typical key-oriented lookup for determining whether an item has already been populated into the cache.
The code for pre-loading of entries into the cache needs to use the same key value as a regular cache lookup will use.
- The default cache key generation system may not be appropriate.
- The key generation settings need to be kept in sync between the pre-loader and the regular fetcher.
Unit testing the service layer
By setting up a unit test for the pre-loading of each cache we have added some automated checking of the cache key generation.
The steps required are:
- Mocking of DAO for service layer to use in tests
- Calling service layer with known parameters
- Generating expected cache key with same known parameters
- Asserting that the expected cache key matches with the key of the cached entry.
Sunday, 4 December 2011
Company Christmas Party
Recently the company that I currently work for acquired 80% ownership of an e-commerce company that I previously worked for.
I'll see a few more familiar faces at the Christmas party this week.
With a bit of luck I might even do some match-making - borrowing a developer to give the team a hand for my current project.
I'll see a few more familiar faces at the Christmas party this week.
With a bit of luck I might even do some match-making - borrowing a developer to give the team a hand for my current project.
Tuesday, 22 November 2011
Hey, that's cool! - Contagious enthusiasm
I find it fun to work with young developers, their enthusiasm and willingness to learn new things makes leading the way less of a chore and more of a privilege.
Today was a great example. Late in the day I set up a user account in Jira and emailed it across to the newest member of the team. As we got ready to shut down our development for the day he said something along the lines of, "Hey, that's cool. I'll definitely be using this. I've only used bugzilla before, but this looks heaps better. Can it integrate with tasks in eclipse?" ...
The next ten minutes flew by as I gave a brief demo of the plugin, including uploading/downloading of contexts. Then it was time to show how the subversion check-in comments automatically tie together which files were updated for each task.
I think the next step will be to get Jenkins running on a shared server instead of just on my laptop.
Sunday, 20 November 2011
Auto-Refreshing Caches - Part 1
Introduction
This blog entry provides an overview of my recent experience of developing a software system which keeps its core data fresh and ready to be presented to users.
It is a work in progress, so may end up spanning a few posts.
What do I mean by an auto-refreshing cache?
A cache which has its content pre-loaded and refreshed automatically without user action.
Why do I want an auto-refreshing cache?
The desired time for displaying content on screen is less than the time required to fetch the data from the data source across the network - by orders of magnitude.
The remote data source and network connection are beyond our control.
There's more than one way data can change over time
There are two primary ways in which the data in this system changes over time, which should be reflected in the state of the cache:
- Data that should no longer be displayed because it is no longer relevant
- Data properties that change over time
Automating removal
The data to be cached includes some date and time properties which can be used as a basis for removal from the cache.
Due to the diverse nature of the data we have multiple caches. In some caches an entity has its own entry keyed by a unique identifier, while in other caches multiple entities are grouped together by a key generated from the criteria used for the data source lookup (e.g. date and group id).
For the grouped data, the approach for removing expired data involves:
- iterating over the cache entries
- checking that the overall cache entry is not due to expire
- obtaining a write lock on the cache entry
- iterating over the entities contained in the cached data structure and removing those that are expired
- putting the updated data back into the cache
- releasing the write lock on the cache entry
Automating updates of existing entries
For data which is already held in the cache and is not ready to be removed, we can re-fetch the data from the data source and write it into the cache.
This blog entry provides an overview of my recent experience of developing a software system which keeps its core data fresh and ready to be presented to users.
It is a work in progress, so may end up spanning a few posts.
What do I mean by an auto-refreshing cache?
A cache which has its content pre-loaded and refreshed automatically without user action.
Why do I want an auto-refreshing cache?
The desired time for displaying content on screen is less than the time required to fetch the data from the data source across the network - by orders of magnitude.
The remote data source and network connection are beyond our control.
There's more than one way data can change over time
There are two primary ways in which the data in this system changes over time, which should be reflected in the state of the cache:
- Data that should no longer be displayed because it is no longer relevant
- Data properties that change over time
Automating removal
The data to be cached includes some date and time properties which can be used as a basis for removal from the cache.
Due to the diverse nature of the data we have multiple caches. In some caches an entity has its own entry keyed by a unique identifier, while in other caches multiple entities are grouped together by a key generated from the criteria used for the data source lookup (e.g. date and group id).
For the grouped data, the approach for removing expired data involves:
- iterating over the cache entries
- checking that the overall cache entry is not due to expire
- obtaining a write lock on the cache entry
- iterating over the entities contained in the cached data structure and removing those that are expired
- putting the updated data back into the cache
- releasing the write lock on the cache entry
Automating updates of existing entries
For data which is already held in the cache and is not ready to be removed, we can re-fetch the data from the data source and write it into the cache.
Wednesday, 19 October 2011
Ensuring your threads shut down
A while ago I joined a project which had some old school (naive) approaches to concurrent processing in an object oriented language.
In these enlightened times I automatically double check whenever I see a Java class that has been declared with "extends Thread" (not just because some former colleagues regarded the extends keyword as blasphemy).
I've read enough to know to prefer implementing an interface rather than extending a concrete class. In this case the appropriate Interface is Runnable, without even delving into the excellent java.util.concurrent APIs.
For this most recent project I have gradually eliminated all "extends Thread", sometimes by simply implementing Runnable, and sometimes by introducing a TimerTask.
Today I have been troubleshooting some problems which our Java application has when interacting with native code (compiled C++ libraries for interacting with hardware). As part of this exercise the application needed to be overhauled to ensure that all threads that are started are correctly shut down when Tomcat is shutdown.
jvisualvm proved to be a useful tool once again for inspecting which threads were not terminating when I ran the application on my laptop.
Like practically everything else in programming, assigning a useful name to each and every Thread and Timer made it so much easier to trace.
Remember the @PreDestroy annotation is your friend.
In these enlightened times I automatically double check whenever I see a Java class that has been declared with "extends Thread" (not just because some former colleagues regarded the extends keyword as blasphemy).
I've read enough to know to prefer implementing an interface rather than extending a concrete class. In this case the appropriate Interface is Runnable, without even delving into the excellent java.util.concurrent APIs.
For this most recent project I have gradually eliminated all "extends Thread", sometimes by simply implementing Runnable, and sometimes by introducing a TimerTask.
Today I have been troubleshooting some problems which our Java application has when interacting with native code (compiled C++ libraries for interacting with hardware). As part of this exercise the application needed to be overhauled to ensure that all threads that are started are correctly shut down when Tomcat is shutdown.
jvisualvm proved to be a useful tool once again for inspecting which threads were not terminating when I ran the application on my laptop.
Like practically everything else in programming, assigning a useful name to each and every Thread and Timer made it so much easier to trace.
Remember the @PreDestroy annotation is your friend.
Thursday, 13 October 2011
Facebook reverse psychology on privacy
I have recently taken a few weeks off work to travel back to my home country to catch up with friends and family, and soak up some of the Rugby World Cup hype.
When it came time to look for contact details for various friends who I hadn't seen for a while, I ended up resorting to Facebook messaging.
A while ago Facebook opened some loophole which allowed me to see contact phone numbers for anyone who I was a Facebook friend with. I quickly thought of that as a not-so-good idea and opted out, but recently I have been thinking this may have been a cunning ploy by Facebook to ensure that Facebook messaging becomes the primary means of communication for situations such as mine.
One of these days I will probably leave Facebook, as it is becoming too ubiquitous so must inevitably be avoided.
Subscribe to:
Posts (Atom)