Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 52817 invoked from network); 12 Dec 2005 22:14:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Dec 2005 22:14:53 -0000 Received: (qmail 30256 invoked by uid 500); 12 Dec 2005 22:14:48 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 30215 invoked by uid 500); 12 Dec 2005 22:14:48 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 30204 invoked by uid 99); 12 Dec 2005 22:14:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2005 14:14:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of janb@mortbay.com designates 209.235.255.182 as permitted sender) Received: from [209.235.255.182] (HELO jetty3.inetu.net) (209.235.255.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2005 14:14:47 -0800 Received: (qmail 3915 invoked from network); 12 Dec 2005 22:14:24 -0000 Received: from cpe-144-133-196-185.nsw.bigpond.net.au (HELO ?192.168.8.5?) (janb@144.133.196.185) by jetty3.inetu.net with AES256-SHA encrypted SMTP; 12 Dec 2005 22:14:24 -0000 Message-ID: <439DF62F.6050709@mortbay.com> Date: Tue, 13 Dec 2005 09:14:07 +1100 From: Jan Bartel User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: WADI integration References: <4398869C.5090900@earthlink.net> <4398C662.3020904@apache.org> <439ACB72.9080701@coredevelopers.net> <439DD229.7040800@earthlink.net> In-Reply-To: <439DD229.7040800@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dave, I'll quickly address a couple of your points re WADI in Geronimo and leave Jules/Jeff to respond to the rest. > Will WADI ongoing enhancements be easily integrated into an existing > Geronimo v1 installation on a user machine or is a geronimo rebuild > required? That's a little difficult to answer. The level of integration at the moment means that Geronimo directly depends on only a single WADI class, reducing the possibility of a full rebuild, and making it very likely that enhancements will be a drop-in replacement set of WADI jars. Of course, that may change down the road a bit. > Looking forward to seeing the "Getting Started" document. Any hints > currently available on how to setup WADI within geronimo? How to set up WADI with Jetty as the container: /wadi false org.codehaus.wadi.jetty5.JettyManager How to set up WADI with Tomcat as the container: /myapp false WADI Other than that, you need to have some wadi descriptors in your WEB-INF and a couple of jars in WEB-INF/lib depending on which features of wadi you are using (for example, you may need the axion jar in WEB-INF/lib). We are working on more doco, but for now, here's a link to the "Getting Started" doco on the WADI site: http://wadi.codehaus.org/getting-started/index.html Jeff and I have begun discussing how to move the WADI setup from container-specific configuration into the generic Geronimo web schema, so stay tuned for developments in Geronimo 1.1. cheers Jan Dave Colasurdo wrote: > Jeff/Jules, > > Thanks for the update.. > > I'm wondering what the best bet is for Web-Tier clustering for Geronimo > v1 users. Jeff had introduced some GBean changes awhile back to > temporarily enable Tomcat clustering independent of WADI. Now that a > portion of WADI has been introduced into Geronimo v1, I'm wondering > which option is best for v1 users. Clearly, WADI is the better > long-term solution, just wondering if it will provide comparable > capability to straight Geronimo tomcat clustering in the G v1 timeframe. > > Of course, more questions... > > Will WADI ongoing enhancements be easily integrated into an existing > Geronimo v1 installation on a user machine or is a geronimo rebuild > required? > > Looking forward to seeing the "Getting Started" document. Any hints > currently available on how to setup WADI within geronimo? > > What is the current best bet for httpsession replication (for failover) > of 3-4 cluster members? Is the database performance worse than the > 1->all memory replication? > > Does/will WADI allow for cluster members to exist on multiple subnets? > > Thanks > -Dave- > > > Jules Gosnell wrote: > >> Jeff Genender wrote: >> >>> Dave, >>> >>> Thanks for noticing ;-) >>> >>> Dave Colasurdo wrote: >>> >>>> I see that WADI has recently been integrated into Geronimo. >>>> Great Job!!! >>>> >>>> Can someone please provide a quick high level description of what >>>> is/isn't available from WADI in Geronimo v1? >>>> >>>> Tomcat clustering >>> >>> >>> >>> >>> Yes >>> >>>> Jetty clustering >>> >>> >>> >>> >>> Yes >>> >>>> Load Balancing >>> >>> >>> >>> >>> Yes through AJP >>> >>> I will let Jules go into the rest when he wakes up and give a proper >>> response. >> >> >> >> >> Thanks, Jeff, >> >> Load-balancing : >> >> We don't ship our own load-balancer. WADI's philosophy is that the >> load-balancer is part of the deployment environment into which it must >> fit. WADI will work with any load-balancer. It is likely that >> companies will have spent thousands of dollars on state of the art >> hardware and will not want to be constrained into running a free java >> load-balancer on a linux box, just so that they can run WADI. Many >> open source load-balancers are available, if you are not in this >> situation. Apache HTTPD/Mod_JK is common solution. >> >>> >>>> HttpSession failover >>> >>> >>> >> This is implemented by maintaining and frequently refreshing redundant >> off-node copies of session data. >> >> We have a preliminary impl in place, but it is only hooked up to a DB >> backend - full in-vm replication is the goal - a cuple of months away, >> hopefully. >> >>>> -file based >>> >>> >>> >> We have a file-system based persistant store - this could be extended >> for replication. >> >>>> -database >>> >>> >>> >> We have a store, tested on mysql, that can be used for long-term >> persistance, paging and replication - slow. >> >>>> -mem to mem (one to all) >>> >>> >>> >> You will be able to do one to all - but it is not the intended default >> - it doesn't scale further than a few nodes. >> >>>> -mem to mem (one to one/several) >>> >>> >>> >> This is the current plan. I expect most sites to maintain one or two >> redundant copies. This should increase session availability >> sufficiently for most deployments. >> >>>> -distributed cache >>> >>> >>> >> specifically for sessions - running, but not yet production-ready. The >> Getting Started guide on the website, will, when it is published (over >> the next few days) walk you through examples. >> >> generalised, for use with application space POJOs - via a JCache API - >> on the roadmap, but NYI. >> >>>> Sticky Session >>> >>> >>> >> Depends on the load-balancer. We have an integration for mod_jk. More >> integrations (just a pluggable class) will be written as and when the >> need arises. They will generally just manipulate cookies or the >> session id. Many load-balancers that are simply associating cookies >> with nodes internally, will not need any form of integration, they >> will just work . >> >>>> Cluster membership (manual, auto-discovery) >>> >>> >>> >> Auto-discovery - we sit on top of activecluster which provides >> services such as the cluster abstraction, membership change >> notification and death detection. On top of this WADI provides a >> self-partitioning, self-healing substrate, the basis of a distributed >> hash table in which sessions are and later POJOs will be stored. >> >>>> Centralized/independent mgmt >>> >>> >>> >> Currently independant, I guess - via JMX, with which WADI components >> may be registered as they are built by Spring, via their JMX Exporter. >> We have opened various channels to talk about centralised management, >> but have no concrete design as yet. >> >>>> Deployment (independent, centralized, farming) >>> >>> >>> >> In my peripheral vision, not currently a core part of WADI, although >> definitely required for Geronimo clustering. This is part of some >> wider discussions which need to be held soon. Exactly how WADI core or >> extended technology may be fitted into this remains to be decided. >> >>>> Anything above Web Tier clustering? >>> >>> >>> >> Yes. We have started our OpenEJB SFSB integration. SFSBs, in >> clustering terms, behave very similarly to HttpSessions. Gianny Damour >> is working on this. It won't be in Geronimo-1.0, but we hope that it >> is not too far away. We are also looking at application-server level >> abstractions, such as User and Application level sessions, which will >> allow Geronimo to maintain the colocation of all resources related to >> a user or a user/application interaction. The POJO stuff discussed >> above will give us application space capability. Then we are left with >> things like farmed deployment etc, that you have also mentioned. >> >>>> >>>> Thanks >>>> -Dave- >>> >>> >>> >> Hope that helps, Dave. >> >> If you are at ApacheCon, I shall be around from monday til thursday - >> drop me a mail and we can hook up. >> >> Jules >> >> >