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
