A terabyte cache with the RESTful Ehcache Server

The RESTful Ehcache Server is designed to achieve massive scaling using data partitioning – all from a RESTful interface. The largest ehcache single instances run at around 20GB in memory. The largest disk stores run at 100Gb each. Add nodes together, with cache data partitioned across them, to get larger sizes. 50 nodes at 20GB gets you to 1 Terabyte. 
Two deployment choices need to be made: where is partitoning performed, and is redundancy required? These choices can be mixed and matched with a number of different deployment topologies.
This topology is the simplest. It does not use a load balancer. Each node is accessed directly by the cache client using REST. No redundancy is provided. 
The client can be implemented in any language because it is simply a HTTP client. It must work out a partitioning scheme. Simple key hashing, as used by memcached, is sufficient. Here is a Java code sample:
String[] cacheservers = new String[]{“cacheserver0.company.com”, “cacheserver1.company.com”, “cacheserver2.company.com”, “cacheserver3.company.com”, “cacheserver4.company.com”, “cacheserver5.company.com”};
Object key = “123231”;
int hash = Math.abs(key.hashCode());
int cacheserverIndex = hash % cacheservers.length;
String cacheserver = cacheservers[cacheserverIndex];
Redundancy is added as shown in the above diagram by:
  1. Replacing each node with a cluster of two nodes. One of the existing distributed caching options in ehcache is used to form the cluster. Options in ehcache 1.5 are RMI and JGroups-based clusters. Ehcache-1.6 will add JMS as a further option.
  2. Put each ehcache cluster behind VIPs on a load balancer.
Interestingly, content-switching load balancers support URI routing using some form of regular expressions. So, you could optionally skip the client-side hashing to achieve partitioning in the load balancer itself. For example:
/ehcache/rest/sampleCache1/a* => cluster1
/ehcache/rest/sampleCache1/a* => cluster2
Things get much more sophisticated with F5 load balancers, which let you create iRules in the TCL language. So rather than regular expression URI routing, you could implement key hashing-based URI routing. Remember in Ehcache’s RESTful server, the key forms the last part of the URI. e.g. In the URI http://cacheserver.company.com/ehcache/rest/sampleCache1/3432 , 3432 is the key. See http://devcentral.f5.com/Default.aspx?tabid=63&PageID=153&ArticleID=135&articleType=ArticleView for a sample URI hashing iRule.

IntelliJ 8 milestone 1 rocks!

IntelliJ 8 milestone 1, a.k.a. Diana rocks! For the non-IntelliJ users of this world, 8m1 was released in the last week.
IntelliJ 7 annoyed me. It was slow and bloated. Some stuff was added in without enough thought. The facets feature, which I was unable to turn off irritated me so much I logged a bug about it. It sort of felt like the philosophy of Idea had been abandoned.
When you start 8 it asks you what features you want. You are warned that they come at a cost. There are more features than 7. You can always turn them on later, presumably by adding the plugin. The first example is RCSs. I just added svn, as that is all I am using these days. You then go through a series of screens
So, I added what I need and voila! – all of the 7 sluggishness has gone.
I have now changed to 8 full time.

RESTful, resource-oriented caching now available in ehcache-server

I have just released ehcache-server-0.3, which includes a fully functional RESTful, resource-oriented implementation. The standalone-server has also been updated to 0.3.

Cache API

CacheManager Resource Operations
Lists the methods supported by the CacheManager resource
Lists the Caches in the CacheManager.
Cache Resource Operations
OPTIONS /{cache}/
Lists the methods supported by the Cache resource
GET /{cache}
Lists the elements in the cache.
PUT /{cache}
Creates a Cache using the defaultCache configuration.
DELETE / {cache}
Deletes the Cache.
Element Resource Operations
OPTIONS /{cache}/{element}
Lists the methods supported by the Element resource
HEAD /{cache}/{element}
Retrieves the same metadata a GET would receive returned as HTTP headers. There is no body returned.
GET /{cache}/{element}
Gets the element.
HEAD /{cache}/{element}
Gets the element’s metadata.
PUT /{cache}/{element}
Puts and element into the Cache.
DELETE / {cache}/{element}
Deletes the element from the cache.

Continue reading

Spnego 1.1 (Kerberos between browsers and Java App servers) released

Spnego is an SPNEGO and Kerberos plugin for Glassfish. SPNEGO stands for Simple and Protected GSSAPI Negotiation Mechanism. SPNEGO is a standard GSSAPI pseudo-mechanism for peers to determine which GSSAPI mechanisms are shared, select one and then establish a security context with it. Kerberos is a computer network authentication protocol, which allows individuals communicating over an insecure network to prove their identity to one another in a secure manner. Spnego is available under a CDDL v1.0 open source license and is actively developed, maintained and supported.
Version 1.1 has just been released.
Building from source was problematic for the 1.0 release due to some dependencies on snaphot versions. This has been fixed in 1.1.
Version 1.1 has been released as tarballs and also into java.net’s Maven repository.
The spnego web site also has a new home: http://spnego.dev.java.net. Previously we were redirecting to another site which would work with the maven site plugin. Those issues have been overcome.
The documentation has been extensively revised, based on issues that were causing new users to trip up.
Spnego has been also been tested with Glassfish V2 UR1 and Java 6 update 7.
See the project at http://spnego.dev.java.net.