You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Rajith Attapattu <ra...@gmail.com> on 2008/01/29 18:00:53 UTC
Synapse clustering
folks,
For clustering support are we leveraging the underlying Axis2 clustering
functionality?
Can somebody elaborate a bit about how this is done and what use cases we
support currently
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Synapse clustering
Posted by Rajith Attapattu <ra...@gmail.com>.
On Jan 30, 2008 5:03 AM, Afkham Azeez <af...@gmail.com> wrote:
> 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.
Agree with Azeez. During the f2f we discussed the option of locking and we
decided against it for the reasons stated above.
As long as we communicate clearly (Ruwans email indicates we have done that)
to the users that there is a limitation then it is fine.
Rajith.
>
>
> Azeez
>
>
> On Wed, Jan 30, 2008 at 12:35 AM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> >
> >
> > On Jan 29, 2008 1:13 PM, Ruwan Linton <ru...@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
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Synapse clustering
Posted by Afkham Azeez <af...@gmail.com>.
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 <ra...@gmail.com>
wrote:
>
>
> On Jan 29, 2008 1:13 PM, Ruwan Linton <ru...@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
Re: Synapse clustering
Posted by Rajith Attapattu <ra...@gmail.com>.
Ruwan,
Sure, I will first wrap up the AMQP transport and then do this guide.
Regards,
Rajith
On Jan 30, 2008 10:39 AM, Ruwan Linton <ru...@gmail.com> wrote:
> Rajith,
>
> By the way, would you like to contribute a guide on clustering and its
> limitations to synapse? (since you know the internals of axis2 clustering
> stuff very well, I think it is good if you can contribute to this)
>
> Thanks,
> Ruwan
>
>
> On Jan 30, 2008 7:56 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
> > My bad, bcos I initially sent it to the wrong list :(.
> >
> > Rajith
> >
> >
> > On Jan 30, 2008 4:30 AM, Asankha C. Perera <as...@wso2.com> wrote:
> >
> > > Guys
> > >
> > > Please do not CC: mails to the old synapse-dev@ mailing list.. The
> > > dev@ list now works fine and so you can all discontinue using the old
> > > lists.. :-)
> > >
> > > thanks
> > > asankha
> > >
> > >
> > > Ruwan Linton wrote:
> > >
> > > Rajith,
> > >
> > >
> > > > > > 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.
> > > >
> > >
> > > Yes, we know this limitation is there. Even we have a JIRA for the
> > > Throttle mediator [1]. This is because there is no distributed locking
> > > mechanism in axis2-clustering implementation. But again we have not came
> > > across any requirement to support that level of replication to happen from
> > > users and most of them are fine with this error.
> > >
> > > [1] - https://issues.apache.org/jira/browse/SYNAPSE-180
> > >
> > > Thanks,
> > > Ruwan
> > >
> > > --
> > > Ruwan Linton
> > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> > >
> > >
> >
> >
> > --
> > Regards,
> >
> >
> > Rajith Attapattu
> > Red Hat
> > blog: http://rajith.2rlabs.com/
> >
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Synapse clustering
Posted by Ruwan Linton <ru...@gmail.com>.
Rajith,
By the way, would you like to contribute a guide on clustering and its
limitations to synapse? (since you know the internals of axis2 clustering
stuff very well, I think it is good if you can contribute to this)
Thanks,
Ruwan
On Jan 30, 2008 7:56 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> My bad, bcos I initially sent it to the wrong list :(.
>
> Rajith
>
>
> On Jan 30, 2008 4:30 AM, Asankha C. Perera <as...@wso2.com> wrote:
>
> > Guys
> >
> > Please do not CC: mails to the old synapse-dev@ mailing list.. The dev@
> > list now works fine and so you can all discontinue using the old lists.. :-)
> >
> >
> > thanks
> > asankha
> >
> >
> > Ruwan Linton wrote:
> >
> > Rajith,
> >
> >
> > > > > 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.
> > >
> >
> > Yes, we know this limitation is there. Even we have a JIRA for the
> > Throttle mediator [1]. This is because there is no distributed locking
> > mechanism in axis2-clustering implementation. But again we have not came
> > across any requirement to support that level of replication to happen from
> > users and most of them are fine with this error.
> >
> > [1] - https://issues.apache.org/jira/browse/SYNAPSE-180
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
> >
>
>
> --
> Regards,
>
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: Synapse clustering
Posted by Rajith Attapattu <ra...@gmail.com>.
My bad, bcos I initially sent it to the wrong list :(.
Rajith
On Jan 30, 2008 4:30 AM, Asankha C. Perera <as...@wso2.com> wrote:
> Guys
>
> Please do not CC: mails to the old synapse-dev@ mailing list.. The dev@
> list now works fine and so you can all discontinue using the old lists.. :-)
>
>
> thanks
> asankha
>
>
> Ruwan Linton wrote:
>
> Rajith,
>
>
> > > > 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.
> >
>
> Yes, we know this limitation is there. Even we have a JIRA for the
> Throttle mediator [1]. This is because there is no distributed locking
> mechanism in axis2-clustering implementation. But again we have not came
> across any requirement to support that level of replication to happen from
> users and most of them are fine with this error.
>
> [1] - https://issues.apache.org/jira/browse/SYNAPSE-180
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Synapse clustering
Posted by "Asankha C. Perera" <as...@wso2.com>.
Guys
Please do not CC: mails to the old synapse-dev@ mailing list.. The dev@
list now works fine and so you can all discontinue using the old lists..
:-)
thanks
asankha
Ruwan Linton wrote:
> Rajith,
>
>
> 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.
>
>
> Yes, we know this limitation is there. Even we have a JIRA for the
> Throttle mediator [1]. This is because there is no distributed locking
> mechanism in axis2-clustering implementation. But again we have not
> came across any requirement to support that level of replication to
> happen from users and most of them are fine with this error.
>
> [1] - https://issues.apache.org/jira/browse/SYNAPSE-180
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: Synapse clustering
Posted by Ruwan Linton <ru...@gmail.com>.
Rajith,
> > > 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.
>
Yes, we know this limitation is there. Even we have a JIRA for the Throttle
mediator [1]. This is because there is no distributed locking mechanism in
axis2-clustering implementation. But again we have not came across any
requirement to support that level of replication to happen from users and
most of them are fine with this error.
[1] - https://issues.apache.org/jira/browse/SYNAPSE-180
Thanks,
Ruwan
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: Synapse clustering
Posted by Rajith Attapattu <ra...@gmail.com>.
On Jan 29, 2008 1:13 PM, Ruwan Linton <ru...@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"
>
Re: Synapse clustering
Posted by Ruwan Linton <ru...@gmail.com>.
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).
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"
Re: Synapse clustering
Posted by Rajith Attapattu <ra...@gmail.com>.
Ruwan, thanks for the excellent explanation.
On Jan 29, 2008 12:30 PM, Ruwan Linton <ru...@gmail.com> wrote:
> Rajith,
>
> We currently supports clustering only over the Caching and Throttling
> mediators. Because synapse instances can share a remote registry to download
> the configuration at startup we can let each and every synapse nodes in a
> cluster to get its configuration from a single registry and start with a
> common configuration, so that we don't need to replicate the configuration.
> Of course if some one changes the configuration of a particular instance,
> that instance will only be changed to the new configuration, but we do not
> expect this to happen in a production environment. Even the user
> requirements which flows in to synapse were aware of that and OK with that.
Yes this make sense.
>
>
> 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?
> As a summary, yes we leverage axis2-clustering functionality but over the
> scope of mediator level, not on the synapse global scope. Any way synapse
> uses the underlying axis2.xml cluster configuration to enable clustering.
>
> I think this explains how we do clustering, if you need further
> clarification please let me know...
Thanks again.
>
>
> Thanks,
> Ruwan
>
>
> On Jan 29, 2008 10:30 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
> > folks,
> >
> > For clustering support are we leveraging the underlying Axis2 clustering
> > functionality?
> > Can somebody elaborate a bit about how this is done and what use cases
> > we support currently
> >
> > --
> > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > blog: http://rajith.2rlabs.com/
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: Synapse clustering
Posted by Ruwan Linton <ru...@gmail.com>.
Rajith,
We currently supports clustering only over the Caching and Throttling
mediators. Because synapse instances can share a remote registry to download
the configuration at startup we can let each and every synapse nodes in a
cluster to get its configuration from a single registry and start with a
common configuration, so that we don't need to replicate the configuration.
Of course if some one changes the configuration of a particular instance,
that instance will only be changed to the new configuration, but we do not
expect this to happen in a production environment. Even the user
requirements which flows in to synapse were aware of that and OK with that.
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.
As a summary, yes we leverage axis2-clustering functionality but over the
scope of mediator level, not on the synapse global scope. Any way synapse
uses the underlying axis2.xml cluster configuration to enable clustering.
I think this explains how we do clustering, if you need further
clarification please let me know...
Thanks,
Ruwan
On Jan 29, 2008 10:30 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> folks,
>
> For clustering support are we leveraging the underlying Axis2 clustering
> functionality?
> Can somebody elaborate a bit about how this is done and what use cases we
> support currently
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"