geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Colasurdo <davec...@earthlink.net>
Subject Re: WADI integration
Date Mon, 12 Dec 2005 19:40:25 GMT
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
> 
> 

Mime
View raw message