Cache is critical for Mobitype.
In fact, every RSS or Atom feed fetched from the Web should be cached. This may avoid much of extra effort on verifying if feed have been changed or not. In fact, once the feed is in the cache, and if Mobitype does not know if the feed have been modified since last lookup, Mobitype may ask a question to the remote server in a form of "Please give me this feed if it has not been modified since last monday?" Most servers could report to this question shortly, saying either "Yes, here is the new version" , or "Just feel free to used your cached one, nothing changed" . This simple algorythm saves terabytes of trafic all over the world, and in fact just every known browser and web server uses it. But we definitely need cache for that.
Mobitype took off with
EhCache 
- a simple non-clustered solution from
SourceForge 
that can keep files in memory for fast access and swaps them to disk in case of memory owerfolw. Simple to configure, it showed up shortly with some decieving drawbacks :(
- Its disk owerflow mecanics is quite fragile. In fact, when a memory store reaches its limit, EhCache starts to enqueue objects to the in-memory spool, and there is a special process that flushes them to disk one by one. This process has, however, a vulnerability, that can be discovered by looking at the source code: whatever unexpected happens while flushing objects to disk, the spooling process may just die, and no more objects will be saved untill next server restart. The spooling queue just grows, untill it occupies all available memory, and server falls down ;[]
- All the cached entries are stored in one geant file, which grows progressively with every new entry, occupying enourmous space and heavily clustered. This file is indexed, and the index is stored in memory until the server is shut down. In case of abnormal server termination, all the index is lost ;( The geant cache file is however not cleaned up, and new entries are just appended th the end,
