geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: WADI clustering
Date Wed, 18 Jan 2006 10:13:09 GMT
Rajith Attapattu wrote:

> More question if you don't mind.
>  
> > 2.) Assuming sombody wants to do session replication (All
> > Active) instead of (one Active and "n" backups) is there provision
> > within the WADI api to plug in this stratergy?
>
> >I'm giving this some thought in terms of SFSB support, I'm not aware of
> >similar constraints in the EJB world...
>
> >I guess we could relax this constraint in the web world, but I am not
> >sure that I think that this is a good idea. Can you see a way to do this
> >and maintain spec compliance and performance ?
> Is WADI designed primarily for Web?? (bcos u talked about being 
> servlet spec compliant) and u also mention about SFSB support.
> Can we abstract the Replication problem to a more higher level and 
> have the two (or more if there is) stratergies as impls of the 
> replication API that installs as a pluggin by the user.
>  
> We can abstract things like a ReplicationManager that handles/controls 
> no of replicas etc.. and a ReplicatedSession which decides wether it's 
> active or passive (backup) based on the parameters passed to the 
> ReplicatedSessionFactory at create time from the ReplicationManager.

This is a very good idea. A ReplicationManager could provide the 
management of replicas: we feed it a "primary" object; it delegates to a 
BackingStrategy the selection of backing storages, i.e. location and 
type of back-ups; and feeds to the selected ReplicaStorage a copy of the 
object to be replicated.

As previously stated by Jules, the BackingStrategy chooses the backing 
storages based on deployment characteristics, e.g. a storage hosted by a 
distinct physical box than the one hosting the "primary" object is 
preferred to a storage hosted on the same physical box than the "primary".

Also, the ReplicationManager could provide some ways to re-organize the 
backing storages, when a session has been migrated from one node to 
another. It notifies the other ReplicationManager hosted by each node of 
the cluster and instructs them that it is becoming the "primary" host of 
a replicated object (this object is uniquely identified by a key 
somehow). The ReplicationManager, which is currently the primary of this 
replicated object, releases the primary and replies back that the 
backing storages are hosted there, there and there. The new "primary" 
host requests to the BackingStrategy to re-assess the backing storages 
based on the new situation: I am now the "primary" host and the current 
backing storages are there.

>  
> The ReplicationManager impl could be the stratergy that decides wether 
> it maintains n of active replicas or 1 active and n backups or any 
> other stratergy.
>  
> Also the ReplicatedSession could impl stratergies like in 
> MemoryReplication or PassiveReplication (based on active or passive) 
> or anything else. And PassiveReplication can be extended to file 
> based, database backed (not recomended) or anything else.

In the above scheme, the ReplicaStorage implements these memory, file or 
database strategies.

Does that sound reasonable?

Thanks,
Gianny

>  
> If we open up the API and let the user choose the stratergy they want 
> then we are delaying our concerns to the user level and allow them to 
> make the decesion.
> I am sure we cannot address every situation, and the user is the best 
> to judge about there env.
>  
> But we can always provide some sensible stratergies and recomendations 
> and use cases around them to make an informed decesion.
>  
> Then We can leave the decesion to the user about 
> spec-complient/performance.
>  
> What do u think??
>  
> >If a request arrives at a secondary, primary and secondary swap roles
> >and processing happens locally.
> >If a request arrives on a node with no copy of the relevant session, it
> >may be relocated to the primary, or the primary to it.
>  
> 1. Do u plan to have an abstraction around the above concerns as well??
>     So we can have impls of different stratergies, So people can 
> decide wether they want to relocate the primary or the request.
>  
>     In case of a relocation of either request or session I assume u 
> have hidden the impls behind an interface/API sort of thing so ppl can 
> do different impls of the same stratergies or impl their own stratergy.
>  
> 2. In the event of a primary and secondary swapping roles or having n 
> of active replicas don't we need some sort of distributed locking 
> mechanism.
> I heard that in memory locking should be optimistic and storage backed 
> replicas should be pessimistic locking.
>  
> I hope I haven't got the too mixed up :)
>  
> Can u please touch on this problem as my knoweldge is limited on this 
> area.
>  
> Regards,
>  
> Rajith.
>
>  
> On 1/17/06, *Jules Gosnell* <jules@coredevelopers.net 
> <mailto:jules@coredevelopers.net>> wrote:
>
>     Rajith Attapattu wrote:
>
>     >
>     >  Hi,
>     >
>     > Some of these questions came up after reading the thread on totem.
>     > However I started the new thread so that searching is easy and also
>     > want distract the intense discussions on totem with out-of-topic
>     > questions.
>     >
>     > Jules Gosnel wrote
>     >
>     > >This is not something that is really considered a significant
>     saving in
>     > >WADI (see my last posting's explanation of why you only want one
>     > >'active' copy of a session). WADI will keep session backups
>     serialised,
>     > >to save resources being constantly expended deserialising session
>     > >backups that may never be accessed. I guess actually, you could
>     consider
>     > >that WADI will do a lazy deserialisation in the case that you have
>     > >outlined, as primary and secondary copies will actually swap
>     roles with
>     > >attendant serialisation/passivation and deserialisation/activation
>     > >coordinated by messages.
>     >
>     > >If you are running a reasonable sized cluster ( e.g. 30 nodes -
>     it's all
>     > >relative) with a small number of backups configured ( e.g. 1),
>     then, in
>     > >the case of a session affinity brekdown (due to the leaving of a
>     > >primary's node), you have a 1/30 chance that the request will
>     hit the
>     > >primary, a 1/30 that you will hit the secondary and a 28/30
>     that you
>     > >will miss :-) So, you are right :-)
>     >
>     > So just to figure out if I understand this correctly.
>     >
>     > 1.) WADI only has one active and one-two backups at most (I
>     assume the
>     > no of backups is configurable)
>
>     replication is under implementation at the moment. Any number of
>     backups
>     should be configurable, but the more you have the less performant you
>     are. You trade off safety for speed.
>
>     >
>     > 2.) WADI is built up on the assumption of session affinity. So the
>     > probability of missing the primary and the secondary backup(s)  goes
>     > up as the cluster grows according to your example
>
>     WADI will work without session affinity, however, as you would expect,
>     this will not perform as well as it might. If you switch on affinity,
>     you will drastically cut down the amount of request/session relocation
>     and most interactions should become local.
>
>     Switch off affinity, and of course, your chances of hitting a copy of
>     the session will go down. There are a fixed number of sessions and
>     you
>     are increasing the number of nodes... If you are intending to use
>     an lb
>     without affinity, then you should really reconsider. The costs are
>     tiny
>     and the gains enormous. Affinity is a standard feature on any serious
>     HTTP LB.
>
>     >
>     > 3.) How does WADI handle a situation where there is no session
>     affinity??
>
>     If a request lands on the primary, processing occurs locally.
>     If a request arrives at a secondary, primary and secondary swap roles
>     and processing happens locally.
>     If a request arrives on a node with no copy of the relevant
>     session, it
>     may be relocated to the primary, or the primary to it.
>
>     >
>     > 4.) Have you compared the overhead of maintaining session
>     affinity vs
>     > having R replicas (all-Active) to service the client.
>
>     I have worked on impls using both approaches and am satisfied that my
>     most recent approach will be the most performant.
>
>     >
>     > >If, however,  you did your deserialisation of replicants up
>     front and
>     > thus avoided further messages when a secondary was hit, by
>     maintaining
>     > >all copies 'active' (I think you would not be spec compliant if you
>     > did this),
>     >
>     > 1.) What do u mean by spec here ?? Are u talking about the WADI
>     spec?
>
>     There is no WADI spec :-) - I'm talking about the servlet spec -
>     specifically :
>
>     SRV 7.7.2 - "Within an application marked as distributable, all
>     requests
>     that are part of a session must be handled by one Java Virtual
>     Machine1
>     ( JVM ) at a time." and "Containers must notify any session attributes
>     implementing the HttpSessionActivationListener during migration of a
>     session. They must notify listeners of passivation prior to
>     serialization of a session, and of activation after
>     deserialization of a
>     session."
>
>     These two constraints make it, IMHO, much more difficult to try
>     implementing any system that maintains multiple 'active', or
>     'primary'
>     copies of a session. The system needs to be absolutely clear where the
>     single 'active' copy is at any one time, in order to remain compliant.
>     To ensure that activation/passivation semantics work OK, only this
>     session may be activated, whilst the other 'secondary' copies are
>     passivated. By leaving the secondaries in serialised form, you save
>     further cycles and arrive at WADI's current design.
>
>     >
>     > 2.) Assuming sombody wants to do session replication (All
>     > Active) instead of (one Active and "n" backups) is there provision
>     > within the WADI api to plug in this stratergy?
>
>     I'm giving this some thought in terms of SFSB support, I'm not
>     aware of
>     similar constraints in the EJB world...
>
>     I guess we could relax this constraint in the web world, but I am not
>     sure that I think that this is a good idea. Can you see a way to
>     do this
>     and maintain spec compliance and performance ?
>
>     >
>     > If u remeber we talked about extention points within WADI.
>     >
>     > 1.) Is there a doc that describes WADI architecture
>
>     Not as yet, just a website with various resources hanging of it.
>     WADI is
>     still relatively young. The best source of architecture info is the
>     conversations that we have been having.
>
>     >
>     > 2.) Is there a doc that describes these extention points and how
>     to do
>     > it?? (Looking for a little more info than the API doc)
>
>     WADI is put together using Spring. You just check out the javadoc and
>     plug the pojos together. A lot of what we have been talking about is
>     architectural design and not implemented (although the
>     primary/secondary
>     stuff is all in and working).
>
>     regards,
>
>
>     Jules
>
>     >
>     > Thanks,
>     >
>     > Rajith.
>     >
>
>
>
>     --
>     "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 <http://www.coredevelopers.net>
>     *
>     * Open Source Training & Support.
>     **********************************/
>
>



Mime
View raw message