You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dave Colasurdo <da...@earthlink.net> on 2005/12/08 20:16:44 UTC
WADI integration
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
Jetty clustering
Load Balancing
HttpSession failover
-file based
-database
-mem to mem (one to all)
-mem to mem (one to one/several)
-distributed cache
Sticky Session
Cluster membership (manual, auto-discovery)
Centralized/independent mgmt
Deployment (independent, centralized, farming)
Anything above Web Tier clustering?
Thanks
-Dave-
Re: WADI integration
Posted by Dave Colasurdo <da...@earthlink.net>.
Jan,
Thanks for the detailed info! Would you know how to tie the
httpsession's to a particular persistence/replication type?
Is this setup independent of WADI or is it tied directly to the WADI
config?
IIRC, straight Tomcat clustering is setup via the Cluster and
ReplicationValve settings in server.xml. Is there a similar concept for
WADI?
-Dave-
Jan Bartel wrote:
> 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:
>
> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0"
> configId="wadi">
>
> <context-root>/wadi</context-root>
> <context-priority-classloader>false</context-priority-classloader>
> <session-manager>org.codehaus.wadi.jetty5.JettyManager</session-manager>
> </web-app>
>
>
> How to set up WADI with Tomcat as the container:
>
> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"
> configId="myapp">
>
> <context-root>/myapp</context-root>
> <context-priority-classloader>false</context-priority-classloader>
> <manager>WADI</manager>
>
>
> <gbean name="WADI"
> class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
> </web-app>
>
> 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
>>>
>>>
>>
>
>
>
Re: WADI integration
Posted by Jan Bartel <ja...@mortbay.com>.
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:
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0"
configId="wadi">
<context-root>/wadi</context-root>
<context-priority-classloader>false</context-priority-classloader>
<session-manager>org.codehaus.wadi.jetty5.JettyManager</session-manager>
</web-app>
How to set up WADI with Tomcat as the container:
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"
configId="myapp">
<context-root>/myapp</context-root>
<context-priority-classloader>false</context-priority-classloader>
<manager>WADI</manager>
<gbean name="WADI"
class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
</web-app>
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
>>
>>
>
Re: WADI integration
Posted by Dave Colasurdo <da...@earthlink.net>.
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
>
>
Re: WADI integration
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
Re: WADI integration
Posted by Jeff Genender <jg...@apache.org>.
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.
> HttpSession failover
> -file based
> -database
> -mem to mem (one to all)
> -mem to mem (one to one/several)
> -distributed cache
> Sticky Session
> Cluster membership (manual, auto-discovery)
> Centralized/independent mgmt
> Deployment (independent, centralized, farming)
> Anything above Web Tier clustering?
>
> Thanks
> -Dave-