geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: WADI clustering
Date Sun, 22 Jan 2006 23:46:30 GMT
Rajith Attapattu wrote:

> >>However if we use 100% session affinity then the chance
> Sorry it should be asume not use. :)
>  
> Don't think of it as a battle, it's a disscussion for me (and perhaps 
> for you) to understand both sides of the coin. Unless u think my 
> questions are stupid :)

Good - I'm glad that we see eye to eye on this one. It is indeed an 
interesting technical debate. I'm just a little paranoid about upsetting 
people at the moment, because I seem to be doing a lot of it :-)

>  
> >>Sorry to put you down again - I don't want to, but when I think it 
> all through, I just can't see a good reason to go this route.....
>  
> >>I am planning to refactor this area in WADI to be pluggable, so you 
> wil have the option of writing something like this if you really want it
>
> Well u haven't put me down, u have agreed to refactor this area in 
> WADI to be pluggable (Thats what I wanted).
> All I am saying is we don't have to go ahead and implement the 
> scenario, but we shouldn't close the door either !!!
> So what your doing will allow a somebody the provision to use it they 
> really want :)

OK - so, we understand each others position much more clearly and have 
what we want. Cool. I have found this thread particularly beneficial 
because you have forced me to crystallise what I felt into hard reason, 
which is a very useful thing to be forced to do. As a result, I now 
understand my position much better and have have noticed a couple of 
further optimisations that I can make :-)

>  
> Ok, so finnaly I have achived what I wanted, that is to open up the 
> API :) and thanks for that.
>  
> State-Balancing
> ----------------------------
> Ok thats what I was looking for. My concern was that if we use session 
> affinity can a server get overloaded. Sorry if never asked about this 
> directly and all credit to you for identifying what my real concern 
> was wrt session affinity.
>  
> It's cool if we have a mechanism if the ClusterManager is aware of no 
> of sessions in each node and make sure new requests are redirected to 
> another node if the current server has already reached the threshold.

I was already intending for each node to publish a rough indication of 
the number of session that it carries, because I figured that it would 
come in useful - we now have a good usecase for it.

>  
> Does WADI provide a management API for this kind of thing??

Not yet - look at the LoadBalancer strategy stuff - it will be extended 
to hang off here somewhere.

>  
> also doe it have some sort of mechanism to get info about a particular 
> node, no of nodes, no of nodes in a session at given time...etc ????

ActiveCluster allows each node to maintain a small amount of published 
data about itself. It can write this data. All other nodes can read it. 
I use it, currently, to advertise human-readable-node-name, http-port, 
shutting-down?, etc... - I figure that if if e.g. the number of sessions 
that you are carrying fluctuates by more than 10% since the last 
published figure, you publish the new number etc. We want to throttle 
publishing a little because each publishing causes a 1->all message...

>  
> I assume u still expose the listerners in ActiveCluster for interested 
> parties to get events like node joined, left ...etc

This area of the code is still undergoing a lot of change, but it should 
be possible to get the ActiveCluster Cluster object from it and attach a 
ClusterListener.

Jules

>  
> Regards,
>  
> Rajith.
>  
> On 1/19/06, *Jules Gosnell* <jules@coredevelopers.net 
> <mailto:jules@coredevelopers.net>> wrote:
>
>     Rajith Attapattu wrote:
>
>     >
>     > Ok, I am not fixed on multiple-active-sessions.
>     > But my concern is high availability with single-active-session
>     model
>     > under high load conditions.
>     >
>     > As u pointed out,
>     > >In the web world, clients commonly throw multiple concurrent
>     requests at
>     > >clusters, however, if we could assure total affinity, these
>     would always
>     > >arrive at the same copy, avoiding the chance of a collision
>     >
>     > However if we use 100% session affinity then the chance of one
>     server
>     > getting too many hits is possible (due to that being the primary
>     and
>     > the LB indiscrimantely maintaining session affinity without due
>     > consideration for load).
>     > Thus a compromise of service quality is inevitable. The service will
>     > have to drop requests or degrade the service (provide only some
>     of the
>     > services which are not expensive).
>     >
>     > So sometimes the cost of maintaining multiple-active-sessions may be
>     > less compared to the exceptional cost that has to be paid with a
>     > server crash thus increasing the load within the remaining nodes of
>     > the cluster.
>
>     I haven't heard this argument before - lets take a look at it...
>
>     I'm not aware of loadbalancers that allow you to ask for e.g. 50%
>     affinity - do they exist ? So, lets look at the extremes (100% and
>     0%),
>     this is often the best way of seeing how something will actually work.
>
>     100%
>     - all requests are routed to the correct node, regardless of
>     cluster size
>     - no replicants ever need to be deserialised because they are
>     never hit
>     - if a node collects too many sessions, it may get overloaded
>
>     0%
>     - the amount of extra deserialisation that you will have to
>     perform will
>     increase in line with the number of nodes in your cluster as the
>     chance
>     of hitting the one deserialised copy decreases.
>     - this extra deserialisation cost will mean that total work done
>     for the
>     same load will be higher and may overload nodes.
>
>     So, I guess we want to choose the solution that leads to the least
>     work
>     being done in the cluster - 100% affinity - and figure out how to
>     avoid
>     so many clients getting stuck to one node that they overload it -
>     solution - state-balancing.
>
>     Each node needs to be aware of roughly how many sessions the other
>     nodes
>     are carrying. If it feels that it has more than everyone else, it
>     could
>     (load-balancer  integration permitting) offload sessions to its peers
>     and relocate subsequent requests for them to their new location, or
>     simply relocate requests that look like they might create a new
>     session
>     to peers that are carrying fewer sessions - or use both of these
>     algorithms to keep state equally balanced across the cluster.
>
>     how does that sound ? It shouldn't be too hard in WADI, because
>     most of
>     the stuff to do this sort of thing is already there...
>
>     >
>     > The cost in terms of money value of loosing revenue due to service
>     > un-availability could be higher than providing more memory,
>     high-speed
>     > network infra which could handle the cost of
>     > serialization/desirialization of replicas and the overhead of a
>     > distributed locking mechanism without compromising performance.
>     >
>     > Thats why I said that we should provide both stratergies and the
>     > end-user can make an informed decesion based on there business
>     > requirments and load conditions within there cluster.
>     >
>     > We should avoid making those decesions before hand.
>     >
>
>     > Also allowing the idea of configurable active replicas will
>     allow the
>     > end-user the flexibility of trying out both multiple-active-session
>     > and single-active-session models and see what works best for them.
>     >
>     > I would strongly advocate the idea of a Replication mgt abstraction
>     > API especially with some of the ideas Gianny provided on the thread.
>     >
>     > What do u think about that?? Have I made a case??
>
>     Hmmm...
>
>     I don't want to make a battle out of this, but I really cannot see
>     any
>     advantage to multiple live copies. All you will do is increase the
>     work
>     that your cluster is having to perform. If you choose 1->few
>     replication, you will also miss your session and its copies with
>     increasing frequency as you add nodes, creating even more work. If
>     you
>     choose 1->all replication you will suffer from increasing workload and
>     memory requirements on all nodes as you add new ones, and you will
>     quite
>     quickly hit a ceiling in terms of scale... Affinity is the silver
>     bullet
>     as far as clustering sessions in concerned. I can't understand why
>     anyone would want to run without affinity turned up as high as it
>     will go.
>
>     I am planning to refactor this area in WADI to be pluggable, so
>     you will
>     have the option of writing something like this if you really want
>     it...but I am not convinced that I should provide it...
>
>     Sorry to put you down again - I don't want to, but when I think it all
>     through, I just can't see a good reason to go this route.....
>
>     Jules
>
>     >
>     > Regards,
>     >
>     > Rajith.
>     >
>     >
>     > On 1/18/06, *Jules Gosnell* <jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>
>     > <mailto: jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>>> wrote:
>     >
>     >     Jules Gosnell wrote:
>     >
>     >     > Oh Rajith - you've got me thinking :-(
>     >     >
>     >     > I'm not happy with the last answer - lets try again....
>     >     >
>     >     > lets agree some points :
>     >     >
>     >     > 1) since changes made to sessions are made in app-space, apps
>     >     are not
>     >     > written with the expectation that a change collision may
>     occur
>     >     and the
>     >     > container would not be able to avoid such a collision, it must
>     >     never
>     >     > happen.
>     >     >
>     >     > 2) in order for a change-collision to occur multiple
>     concurrent
>     >     > requests/invocations must hit multiple copies of the session
>     >     >
>     >     > In the web world, clients commonly throw multiple concurrent
>     >     requests
>     >     > at clusters, however, if we could assure total affinity,
>     these would
>     >     > always arrive at the same copy, avoiding the chance of a
>     collision.
>     >     > There are various situations within the web tier that may
>     cause the
>     >     > breakdown of affinity. Different loadbalancers handle these
>     >     situations
>     >     > with varying degrees of correctness. I have decided that
>     it is safer
>     >     > to assume that, whilst affinity is a substantial
>     optimisation, it
>     >     > cannot be relied on 100%.
>     >     >
>     >     > So, in the web tier, it is possible for concurrent
>     requests for the
>     >     > same session to arrive at different session copies. So we
>     need a
>     >     > pessimistic distributed locking strategy to ensure that
>     >     collisions do
>     >     > not occur.
>     >     >
>     >     > In the EJB world, we have more control over the load-balancer,
>     >     because
>     >     > it is effectively built into the proxy  that we supplied,
>     and we
>     >     could
>     >     > enforce the serial nature of invocations at this point. So it
>     >     might be
>     >     > possible to move forward on the assumption that we don't need
>     >     > pessimistic locking (provided that no-one ever passes a
>     session
>     >     handle
>     >     > to another client).
>     >     >
>     >     > I'm going to give this a little more thought...
>     >     >
>     >     > I think the outcome will be that I can avoid some locking
>     in the EJB
>     >     > world, but need to send the same messages anyway... but
>     we'll see.
>     >     >
>     >     > Thanks for getting me to revisit this,
>     >     >
>     >     BTW - if we do assume that we can rely on affinity 100% in
>     the EJB
>     >     tier
>     >     then I am still not sure that I see any real advantage in
>     holding
>     >     multiple active copies of a session. I guess you will have to
>     >     explain to
>     >     me exactly why you would want to do this.
>     >
>     >     Finally, the locking system that WADI currently uses will
>     only incur
>     >     extra work, taking distributed locks, if affinity breaks
>     down, so the
>     >     cost of applying it to the SFSBs where, we hope for 100%
>     affinity,
>     >     should be 0.
>     >
>     >     Jules
>     >
>     >     >
>     >     > Jules
>     >     >
>     >     >
>     >     >
>     >     > Jules Gosnell wrote:
>     >     >
>     >     >> 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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> WADI was initially designed for the web - because I saw
>     the issues
>     >     >> surrounding HttpSession distribution, particularly the
>     requirement
>     >     >> for a single 'active' session as unresolved in any open
>     source
>     >     >> offering and I thought it was about time that there was a
>     truly
>     >     >> compliant solution.
>     >     >>
>     >     >> It soon became clear that many of the problems faced by
>     >     sessions in
>     >     >> the web-tier were also faced by sessions in the EJB-tier...
>     >     >>
>     >     >>> 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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> Well, we could, but you would have to convince me that
>     SFSBs would
>     >     >> benefit from a 'multiple-active-sessions' approach... I
>     haven't
>     >     given
>     >     >> it much thought, but I don't see any advantage - bear
>     with me :
>     >     >>
>     >     >> - in the EJB world, we own the client side proxy. We can
>     impose
>     >     >> strict affinity. An invocation arriving at a node that is not
>     >     >> carrying the primary session copy will be an exceptional
>     occurance.
>     >     >>
>     >     >> - If you go with the 'single-active-session' model, and an
>     >     invocation
>     >     >> does land on a secondary, you then pay an exceptional cost -
>     >     >> deserialisation and promotion (messaging) from secondary to
>     >     primary.
>     >     >> This is OK, since you are in an exceptional situation.
>     >     >>
>     >     >> - If you go with the 'multiple-active-sessions' approach you
>     >     have two
>     >     >> choices regarding deserialisation of replication messages.
>     >     >>
>     >     >> 1) you can deserialise them as they arrive - bad idea,
>     because
>     >     >> deserialisation is extremely expensive and most of the
>     time these
>     >     >> copies will never be used.
>     >     >> 2) you can deserialise them lazily - only bother to do
>     the work,
>     >     >> if/when an invocation arises.
>     >     >>
>     >     >> Regardless of which you choose (and I hope you would
>     choose 2),
>     >     you
>     >     >> are now in a situation where two copies of a session may
>     >     diverge from
>     >     >> each other. Lets say you make a change to one, then you
>     make a
>     >     change
>     >     >> to the other, but the replication message from the first
>     session
>     >     >> arrives at the second session after your second change
>     and wipes it
>     >     >> out, and the replication message from your second change
>     then
>     >     >> overwrites the first session with what is now a different
>     value
>     >     than
>     >     >> that carried by the second.... you can detect these issues by
>     >     >> versioning, but the best way to protect against them
>     occuring (see
>     >     >> reasons for needing a pessimistic algorithm below) is by
>     having
>     >     some
>     >     >> form of distributed locking. In effect, the guy with the lock
>     >     is the
>     >     >> primary and the guy without it the secondary.
>     >     >>
>     >     >> OK, so now we have a working 'multiple-active-sessions'
>     model -
>     >     but
>     >     >> hold on, it is doing lazy deserialisation and distributed
>     locking -
>     >     >> it looks very like the 'single-active-session' model....
>     >     >>
>     >     >> Does that help ?
>     >     >>
>     >     >>>
>     >     >>> 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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> sure - and all of these things are already pluggable in WADI.
>     >     >>
>     >     >>>
>     >     >>> 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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> Yes it could - but I think that this is still being
>     driven by your
>     >     >> attachment to the multiple-active-sessions model and I do
>     not see
>     >     >> that as viable.
>     >     >>
>     >     >>>
>     >     >>> 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.
>     >     >>>
>     >     >>
>     >     >>
>     >     >>
>     >     >> WADI's replication strategy is already pluggable. We have a
>     >     basic DB
>     >     >> replication scheme and are working on the in-vm scheme.
>     Other
>     >     schemes
>     >     >> could easily be added.
>     >     >>
>     >     >>> 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??
>     >     >>
>     >     >>
>     >     >>
>     >     >> Unless you can demonstrate a clear win for a strategy
>     that is
>     >     >> non-compliant, I would be very hesitant to ship one.
>     >     >>
>     >     >> WADI is designed so that pretty much everything that you
>     might want
>     >     >> to plug is pluggable. But the larger the piece that you
>     want to
>     >     plug
>     >     >> in, the more work you would have to do writing it and
>     making sure
>     >     >> that it did not collide with any other fn-ality.
>     >     >>
>     >     >>>
>     >     >>> >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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> yes - this decision is pluggable.
>     >     >>
>     >     >>>
>     >     >>>     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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> yes
>     >     >>
>     >     >>>
>     >     >>> 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.
>     >     >>
>     >     >>
>     >     >>
>     >     >> session locking has to be pessimistic, because changes
>     are made by
>     >     >> app, not container code. So a collision of changes could
>     not be
>     >     >> resolved by the container, so it cannot be allowed to happen.
>     >     >>
>     >     >> WADI contains a distributed locking mechanism within its
>     >     Partitioning
>     >     >> system. When a copy is promoted, a message will pass from it
>     >     >> (containing its version number), to its partition (where it
>     >     will take
>     >     >> a lock and find the location of the primary), on to the
>     primary
>     >     >> (where it will compare version numbers), back to the
>     secondary
>     >     (with
>     >     >> a possible update, if its version is out of date) and finally
>     >     back to
>     >     >> the partition (where the primary's new location will be
>     stored and
>     >     >> the lock released). local locking will also occur around both
>     >     >> secondary and primary whilst they are involved in this
>     >     interaction.
>     >     >>
>     >     >>>
>     >     >>> I hope I haven't got the too mixed up :)
>     >     >>
>     >     >>
>     >     >>
>     >     >> No, I don' think so, but I do think that you need to take
>     a careful
>     >     >> look at exactly how you think a mutiple-active-sessions model
>     >     might
>     >     >> work and whether this would, in fact, be any different
>     from the
>     >     model
>     >     >> that I am proposing.
>     >     >>
>     >     >>>
>     >     >>> Can u please touch on this problem as my knoweldge is
>     limited on
>     >     >>> this area.
>     >     >>
>     >     >>
>     >     >>
>     >     >> is this enough detail ? :-)
>     >     >>
>     >     >>
>     >     >> Jules
>     >     >>
>     >     >>>
>     >     >>> Regards,
>     >     >>>
>     >     >>> Rajith.
>     >     >>>
>     >     >>>
>     >     >>> On 1/17/06, *Jules Gosnell* <jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>
>     >     <mailto: jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>>
>     >     >>> <mailto: jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>
>     >     <mailto: 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>
>     >     < http://www.coredevelopers.net> <
>     http://www.coredevelopers.net>
>     >     >>>     *
>     >     >>>     * Open Source Training & Support.
>     >     >>>     **********************************/
>     >     >>>
>     >     >>>
>     >     >>
>     >     >>
>     >     >
>     >     >
>     >
>     >
>     >     --
>     >     "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>
>     < http://www.coredevelopers.net>
>     >     *
>     >     * Open Source Training & Support.
>     >     **********************************/
>     >
>     >
>
>
>     --
>     "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.
>     **********************************/
>
>


-- 
"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.
 **********************************/


Mime
View raw message