|Sent on:||Thursday, May 31, 2012 12:23 PM|
Speaking of BigMemory - has anyone any experience of their handmade off-heap memory allocation implementation?
By putting the data outside the heap does not make the underlying problem of garbage collection suddenly vanished, does it?
If the data becomes obsolete, it must be deallocated and the memory space rearranged to prevent fragmentation over time.
They are damning the long pauses created by mark and sweep algorithm (and even G1), but writing & reading data through direct data buffers with serialization/deserialization process takes time too.
Of course they have much narrower range of use cases to be worried about than the gc designers. Also they can utilize the information in hand about eviction policies and the semantics of the data.
If you're talking about having a cache of hundreds of Gigabytes in a single JVM then I agree with you, unless you're comfortable having pauses that can last several minutes eventually. In that case, you'll probably need to think about high availability in case that JVM goes down, but that's another story.
OTOH, the Hotspot is very competitive (and getting better over time) when it comes to less dramatic sizes, with a little bit of tuning: I've seen 30Gb heaps used as caches that caused less than 2 seconds full garbage collections pauses.
Jame's use case is that data is ever added once a week, so assuming the data size is not massive, there'll be very little stress in garbage collection terms.
Back to Infinispan, which is a datagrid rather than a 'classic' cache, you can have, for example, hundreds of nodes in a cluster that can combine their heaps to form a massive consistent cache. Replication, fail-over, high availability and elasticity is what you gain by using an architecture like that; you add nodes and they're automatically discovered and become available to hold data; if a nodes crashes, the data is available on other nodes due to replication.
That doesn't mean you need to think upfront in having dozens of machines to use Infinispan; you can start as a simple as a local-only cache that from the programming point of view, is just a Cache interface, no network involved. And it's very easy to go from a local cache to a distributed one (as described above) in case requirements change in the future: it's mainly a matter of configuration.
Lähettäjä: [address removed] [[address removed]] käyttäjän Kevin Wright [[address removed]] puolesta
Lähetetty: 30. toukokuuta[masked]:36
Vastaanottaja: [address removed]
Aihe: Re: [ljc] Open Source Java Caching APIs
Generally speaking, I advise against caching within the JVM heap - it's really not optimised for this use case as cached objects typically live long enough to escape the eden generation, at which point they'll be putting extra pressure on garbage collection.
If you can, cache as close to the edge as possible, varnish is a very effective solution if you have a restful architecture.
If you can't, still try and push it out of the heap. Consider using memcached or perhaps a commercial solution like bigmemory.
Or if you're feeling really adventurous you can use a memory mapped file (http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ314_029.htm) and manage your own indexes into the thing. If you do this, be aware that's it's genuinely advanced stuff, and that you'll be reinventing the wheel - it's the same approach that varnish and bigmemory use already :)
On 30 May[masked]:45, James Bowkett <[address removed]> wrote:
I am looking to create a caching layer in my application. My application has model objects that require a few costly, star-like SQL queries to construct, this data is only ever added-to once per week. So I plan to create the whole object population once and use an object cache for fast key-based lookup and I'm looking for some opinions/recommendations/conjecture on appropriate technologies.
I really only want a HashMap that pages its values to disk (I'm not afraid to write it myself, but I'd rather use an open source API (the budget for this is my time only) if there's one available and it's nice and lightweight)
Has anyone used Ehcache?....what are your thoughts?....has anyone used any of the other open source alternatives?....Are there any alternatives that I should be looking at instead?
I'm finding it hard to find many APIs out there (most of the projects listed here: http://java-source.net/open-source/cache-solutions are really old). has caching fallen out of favour in preference for some other way of doing things?...or is everyone using things like NoSQL to distribute their caches? (If so, is there a particular NoSQL toolset that would be most appropriate for me?...Should I be looking at something like Voldemort?)
P.S. As a footnote, this is the history of caching APIs as far as I can make it out:
As far as I can tell, there was a JSR for this (107) which looks like it's been dormant for a little over 10 years, the reference implementation for this was JCache, and this came out of some functionality in Oracle 9i, this looks like it was then superseded by Apache's JCS (Java Caching System), although all of these now look like fairly dormant projects (JCS last release was 2007).
It looks like Ehcache was originally a fork of JCS (http://commons.apache.org/jcs/JCSvsEHCache.html), (indeed JCS claims to be faster) but is Ehcache now the only open source caching solution out there that's still under active development?