synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Afkham Azeez" <afk...@gmail.com>
Subject Re: Synapse clustering
Date Wed, 30 Jan 2008 10:03:29 GMT
Locking is going to make the system highly inefficient. There are not many
systems in production which do this. e.g. In Tomcat, the default behavior is
to fire & forget (ASYNC) mode of transmitting state info. In Axis2, we
support both SYNC_ACK & ASYNC depending on the level of accuracy you need
and the response time. The replication takes just a few milliseconds. In
caching & throttling, I believe we only replicate the changes and not the
entire map, in which case most of these complications will not exist.

Azeez

On Wed, Jan 30, 2008 at 12:35 AM, Rajith Attapattu <rajith77@gmail.com>
wrote:

>
>
> On Jan 29, 2008 1:13 PM, Ruwan Linton <ruwan.linton@gmail.com> wrote:
>
> > Rajith,
> >
> >
> > > >
> > > > Most part of synapse is stateless and hence does not have any effect
> > > > over clustering, but Caching and Throttling does. So Caching and Throttle
> > > > mediators use the axis2-clustering implementation to replicate the state
of
> > > > those mediators among the cluster within the implementation of those
> > > > mediators it self. Other than that we do not replicate states of synapse
in
> > > > a global scope. I think this model fits for the moment and has performance
> > > > improvements over supporting clustering in a global scope.
> > > >
> > >
> > > Yep I am in agreement. The reason I asked about clustering is bcos of
> > > the recent thread on session mgt and the need to have the session-mediator
> > > state replicated across the cluster (I hope I didn't misunderstand the
> > > requirments here). I was wondering if this sort of thing is trivial to
> > > implement. Like can we replicate any mediator state if we choose to in a
> > > trivial way?
> > >
> >
> > Yes it is, I think the session-mediator has to take the replication in
> > to account (i.e. another state full mediator for synapse :)). If you are
> > using the ConfigurationContext of axis2 (basically the whole context
> > hierarchy) to store the data (for example, the session data table mapped
> > using a session id) ** you just need to call ConfigurationContext.flush();
> > to replicate any data which has been changed after the last replication.
> > Additionally if you need to just replicate some of the properties of the
> > cfgCtx then you can call the the flush method with the property names (see
> > the clustering API for the exact signature of the method, I don't remember
> > that exactly).
> >
>
> Ruwan, once again thank you for the detailed answer. I really appreciate
> it. The reason behind the question "can we replicate any mediator state if
> we choose to in a trivial way?" was to figure out if the current axis2
> clustering support is sufficient.
>
> However we have to be careful when replicating mediator state especially
> when there are concurrent modifications on different nodes. This can cause
> undesired affects and it is a limitation in our current clustering
> implementation. So even for the session map, if two nodes modify the map
> concurrently we may have issues. This doc explains the limitations
> http://ws.apache.org/axis2/1_3/clustering-guide.html.
> So perhaps it's worthwhile to highlight these issues to synapse users who
> want to tap into the clustering support.
>
> thanks,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
>
> > Or else to replicate the whole context hierarchy you could use
> > Replicator.replicate(); as well. One has to decide the proper method and
> > when to use which by evaluating the complexity and performance of the
> > implementation ....
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
>
>
>


-- 
Thanks
Afkham Azeez

http://azeez78.blogspot.com
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760

Mime
View raw message