« July 2008 | Main | September 2008 »

August 23, 2008

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.
















Posted by gluck at 04:56 PM | Comments (0)

August 16, 2008

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.

Posted by gluck at 08:48 PM | Comments (0)

August 14, 2008

Customer Snapshot: Wotif.com

Wotif.com are using quite a lot of open source software from Sun. This has been written up in a new Customer Snapshot.

Posted by gluck at 10:19 AM | Comments (0)

August 03, 2008

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
OPTIONS /
Lists the methods supported by the CacheManager resource

GET /
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.

Simple Client Example

There is no client for the RESTful cache server. You can use any HTTP client library in any language.

Put XML into cache
String xmlDocument = "\n" +
"\n" +
"Say goodnight,\n" +
"Gracie.
\n" +
"Goodnight, \n" +
"Gracie.
\n" +
"\n" +
"
";

HttpUtil.put("http://localhost:8080/ehcache/rest/sampleCache2/2", "application/xml",
new ByteArrayInputStream(xmlDocument.getBytes()));

The server will respond with 201 for success.


Get XML example

HttpURLConnection urlConnection = HttpUtil.get("http://localhost:8080/ehcache/rest/sampleCache2/2");
assertEquals(200, urlConnection.getResponseCode());
assertTrue(urlConnection.getContentType().matches("application/xml"));

DocumentBuilder documentBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document document = documentBuilder.parse(urlConnection.getInputStream());

XPath xpath = XPathFactory.newInstance().newXPath();
String expression = "/oldjoke/burns";
Node node = (Node) xpath.evaluate(expression, document, XPathConstants.NODE);

assertEquals("burns", node.getNodeName());

The server will respond with 200 for success and provide the data along with Content Type of "application/xml"

Get with wget example
This one shows how to do a get with the Unix utiiity wget:

wget -S http://localhost:8080/ehcache/rest/sampleCache2/1
--15:11:54-- http://localhost:8080/ehcache/rest/sampleCache2/1
=> `1'
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Server: GlassFish/v3
Expires: Sun Aug 17 17:12:55 EST 292278994
Last-Modified: Sun, 03 Aug 2008 05:07:50 GMT
ETag: "1217740070067"
Content-Type: application/octet-stream
Content-Length: 512
Date: Sun, 03 Aug 2008 05:11:54 GMT
Connection: Keep-Alive
Length: 512 [*/*]

100%[=============================================================================================================>] 512 --.--K/s

15:11:54 (8.28 MB/s) - `1' saved [512/512]

Ehcache server fully supports wget, including the site mirroring capabilities.

Getting Started

Download the server here: http://sourceforge.net/project/showfiles.php?group_id=93232

Read the manual here: http://ehcache.sourceforge.net/documentation/cache_server.html

Check out the project and work your way through the tests. These show how to put and get different content with different mime types and how to use HEAD, PUT, DELETE, OPTIONS and GET. Ehcache server supports conditional GET and follows normal HTTP caching conventions.

I hope to follow up with some articles on how to use ehcache-server with different languages.

Posted by gluck at 05:28 PM | Comments (0)

August 02, 2008

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.

Posted by gluck at 08:33 PM | Comments (0)