We, at Optena, are also working a proposal Geronimo Grid Architecture. How can we involve and contribute in this activity?
-Surendra -- Surendra Reddy Founder and Chief Technology Officer Optena Corporation 2860 Zanker Road, San Jose, CA 95135 [EMAIL PROTECTED] -----Original Message----- From: Dave Colasurdo [mailto:[EMAIL PROTECTED] Sent: Saturday, October 15, 2005 5:05 AM To: [email protected] Subject: Re: Clustering Jules Gosnell wrote: > Jeff Genender wrote: > >> Now that we have achieved the covetted J2EE Certification, we need to >> start thinking about some of the things we will need to have in >> Geronimo in order to be mass adopted by the Enterprise. >> >> IMHO, I think one of the huge holes is clustering. This is a heavy >> need by many companies and I believe that until we get a powerful >> clustering solution into G, it will not be taken as a serious J2EE >> contender. >> >> So, with that said, I wanted to start a discussion thread on >> clustering and what we need to do to get this into Geronimo. I >> personally would like to be involved in this (thus the reason for me >> starting this thread) - yeah, since Tomcat is done, now I am bored ;-). >> >> I was going over the lists and emails and had some great discussion >> with Jules on the WADI project he has built. This seems compelling to >> me. I also noticed Active Cluster as a possibility. >> >> So lets start from the top. Do we use an already available clusering >> engine or do we roll our own? Here is a small list of choices I have >> reviewed and it is by no means complete... >> >> 1) WADI >> 2) Active Cluster >> 3) Leverage the Tomcat Clustering engine >> >> So here are some of my questions... >> >> How complete is WADI and Active Cluster? Both look interesting to me. >> My only concern with Active Cluster is it seems to be JMS based, which >> I think may be slow for high performance clustering (am I incorrect on >> this?). How mature is WADI? > > > Here is a status report on WADI. > > I'm developing it full time. > > A snapshot is available at wadi.codehaus.org - documentation is in the > wiki - at the moment the documentation (rather minimalist) is more up to > date than the snapshot, but I will try to get a fresh one out next week. > > WADI is a plugin HttpSession Manager replacement for Tomcat-5.0/5.5 and > Jetty-5.1/60 (it can actually migrate sessions between all four in the > same cluster). > It comprises a vertical stack of pluggable caches/stores (memory, local > disc, db etc) through which sessions are demoted as they age and > promoted as and when required to service a request. Can you please clarify the purpose of promotion/demotion of httpsessions? Is this a mechanism to age old entries out of the cache? How does this relate to httpsession inactivity timeouts? Is the cache size configurable? > This stack may be connected horizontally to a cluster by inserting a > clustered store, which uses a distributed hash table (currently > un-replicated, but I am working on it) to share state around the > clusters members in a scalable manner. WADI has a working mod_jk > integration. Does this mean that each cluster member shares it's httpsession data with all of the other members (1-> all) or is there the notion of limiting the httpsession replication to one (or a few) designated partners? > > WADI currently sits on top of ActiveCluster, which it uses for > membership notification and ActiveMQ which is used for transport by both > layers. ActiveMQ has pluggable protocols, including a peer:// protocol > which allows peers to talk directly to one another (this should put to > bed fears of a JMS based solution not scaling - remember, JMS is just an > API). So you do not need to choose between WADI and ActiveCluster - they > are complimentary. ActiveCluster can also (I believe) use JGroups as a > transport - I haven't tried it. > > ActiveSpace is another technology in this area (distributed caching) and > it looks as if WADI and ActiveSpace will become more closely aligned. So > this may also be considered a complimentary technology. > > Both Tomcat and Jetty currently have existing clustering solutions. I > looked closely at the Tomcat solutions before starting out on WADI and > knew all about the Jetty solution, because I wrote it :-). WADI is my > answer to what I see as shortcomings in all of the existing open source > approaches to this problem-space. > Can you provide a quick high level description of the advantages of WADI over Tomcat and Jetty clustering solutions? > Some parts of WADI should soon (December) be undergoing some serious > testing. When they pass we will be able to consider them production > ready. Others, notably the distributed hash table are still under > development (although a fairly functional version is available in the > SNAPSHOT). > > I think that, in the same way Tomcat clustering could be enabled easily > in Geronimo, WADI could also be added by virtue of its integration with > Tomcat/Jetty, but I have been concentrating on my distributed hash table > too hard. If anyone is interested in talking further about WADI, perhaps > trying to plug it into Geronimo (It is spring-wired and uses spring to > register its components with JMX. I guess it should be simple to hook it > into the Geronimo kernel in the same way, I just haven't had the time), > or helping out in any way at all, I would be delighted to hear from them. > > I have broached the subject of a common session clustering framework > with members of the OpenEJB team and we have discussed things such as > the colocation of HttpSessions and SFSBs. I believe OpenEJB has been > moving towards JCache to facilitate the plugging in of a clustering > substrate. My distributed hash table is also moving in the same direction. > So, if I understand correctly, you are working towards some common infrastructure with openejb.. though WADI itself, will not address clustering beyond the Web Tier? Thanks for the update! > I hope that gives you all a little more information to go on. If you > have any questions, just fire away, > > > Jules > > >> >> Thoughts and opinions are welcomed. >> >> Jeff > > > >
