« Lots of Java activit... | Main | Are you doing client... »
20051123 Wednesday November 23, 2005

Clustering OSCache For the past few days, I've been tuning and configuring OSCache in a clustered (WebLogic) environment. While setting it up was fairly easy, there was some fundamental concepts that took me a bit to figure out.

First of all, I chose to use JavaGroups instead of JMS. The primary reason behind this was it was easier to configure, but I also discovered that if you use JMS - you have to have a unique "cache.cluster.jms.node.name" property in your oscache.properties file on each server. This means to use OSCache with JMS, you have to build two different EARs. At least that's my impression. If you've figured out a better way to do this, please let me know.

In the application I'm working on, there are 4 different caches: one for Hibernate, and several other ones we've created with OSCache and Spring. For the past week, I developed a feature where we cache a user's account information across the cluster. The feature is more like an HttpSession than a cache b/c it's designed to replicate an authentication token (similar to a session id) across all the master servers.

After much head pounding, I discovered that OSCache doesn't update other nodes in a cluster for inserts and updates. It only broadcasts flushes. After understanding how OSCache works, it was much easier for me to code the solution (sans OSCache). If you'd like to see OSCache support replicating a cache across a cluster, vote for CACHE-96. Posted in Java at Nov 23 2005, 01:05:44 PM MST 8 Comments

Comments:

What cache did you finally use?

Posted by 82.182.214.87 on November 23, 2005 at 03:16 PM MST #

We're still using OSCache, we just understand it's limitations now. For the feature I needed inserts and updates for - I just wrote a workaround to transparently re-authenticate the user if their authentication token is not found on the current server. It's a hack, but it works. I realize we could use Coherence for a replicated caching engine.

Posted by Matt Raible on November 23, 2005 at 07:53 PM MST #

Wow...caching alogorithm...now I am impressed. Hmm I think I know a cool open source project that can use this kind of expertise ;-)

Posted by Jeff Genender on November 23, 2005 at 08:15 PM MST #

Matt - thats one of the reasons why OSCache is so fast, its not slowing down your network replicating everything to every node. It is each nodes own responsibility to populate itself, the only "shared thing" between nodes is the cache invalidation, which would clear the same data on any node that stored it (or so I understand). If you use JMS with OSCache, don't you need to add a JMS server? doesn't this then become a SPOF? which pretty much invalidates the point of clustered replication anyway... you don't get that problem with javagroups. If you are looking for a painless (and free) cache solution that supports clustered replication, look at memcached. Although this not a java solution, its a C app, that has a java API available. Coherence is definately the way to go, if you can afford it!

Posted by Lee on November 24, 2005 at 04:07 AM MST #

I'll second memcached as being a nice solution to the distributed cache problem. I have not used coherence, but it seemed interesting. Not sure when coherence is advantageous (?)...since memcached has done everything I've asked of it...

Posted by ian on November 24, 2005 at 06:59 PM MST #

I have not used coherence, but it seemed interesting. <p/> You can download an eval from tangosol.com. It's a commercial product, but the eval license is a free download and the development license (including support) is also no-charge, with the prices all published for production licensing. <p/> Not sure when coherence is advantageous (?)...since memcached has done everything I've asked of it... <p/> Coherence was around before memcached, so the question is a bit backwards ;-) <p/> Coherence isn't just used for content caching. It is a data management system that can scale out to hundreds of servers and can manage many gigabytes of data without any single points of failure. Basically, you throw data into it and it's there, regardless of whether you add or remove servers (or they accidentally die). You have transactions, query capabilities, parallel grid processing, JMX, near caching, NIO overflow, etc. It's pure Java, and serves as the backbone for a number of exchanges, trading systems, travel systems, logistics systems .. and of course a lot of very busy websites. <p/> Peace.

Posted by Cameron Purdy on November 24, 2005 at 08:25 PM MST #

I had exactly the same problems with JMS and JavaGroups. I have solved this by implementing my own plugins so that I didn't have to patch OsCache. For JMS I used a GUID as node name and for JavaGroups I implemented the other events as well and made them configurable. I haven't donated them back to OsCache yet, but if you are interested in the solution I can send you the code.

Posted by Rintcius Blok on December 07, 2005 at 07:22 AM MST #

As far as the multiple ear problem goes, could you setup a URL provider that points to the different properties files and then reference the correct one thru JNDI / references?

Posted by Bill Davis on December 07, 2005 at 09:53 AM MST #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architect who enjoys developing applications with open source technologies. Contact me for rates.
« December 2008
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today

Recent Entries

Tag Cloud

abbie acegi appfuse denver flex grails gwt hibernate jack java jsf linkedin maven myfaces oscon rails skiing spring springmvc struts struts2 tapestry travel webframeworks wicket