You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Afkham Azeez <af...@gmail.com> on 2007/05/18 13:16:08 UTC
[Axis2] Clustering: Replicating properties in the context hierachy
We have a problem when it comes to replicating properties in our clustering
implementation. There are some properties which are specific to a node,
specially properties in the ConfigurationContext. Some properties are added
by different modules such as Sandesha2, Rampart to the ConfigurationContext.
One thing is that these objects are not serializable, and the other thing is
that these properties should not be replicated. Some information which are
specific to a node may be added to the ConfigurationContexts, and these
should never be replicated.
So there should be some way to inform Axis2 about the properties that need
to be clustered and those that shouldn't be clustered.
I suggest we introduce a new Map to AbstractContext called
clusterableProperties. Stuff that are added to this Map will be replicated,
and the service author/module author has to add the properties that need to
be replicated into the clusterableProperties Map.
Thoughts?
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
In the case of the beans added to the Config context by Rampart/Sandesha2 or
any other module, those should not be replicated, since the other nodes
would have already added these to their respective config contexts already.
-- Azeez
On 5/18/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> As Deepal points out, in a cluster u need an identical set of nodes.
> Thats why at point Chamikara and I suggested loading all nodes from
> central repo using URLBasedAxisConfigurator to ensure identical
> configuration.
> Afkam, if there are nodes specific properties, then this application might
> not be a good candiate for clustering.
>
> As for Rampart and Sandesha, can these properties be made serializable?
> Chamikara what are your thoughts on this?
>
> Regards,
>
> Rajith
>
> On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> >
> >
> >
> > On 5/18/07, Deepal Jayasinghe < deepal@opensource.lk> wrote:
> > >
> > >
> > >
> > > Afkham Azeez wrote:
> > > > We have a problem when it comes to replicating properties in our
> > > > clustering implementation. There are some properties which are
> > > > specific to a node, specially properties in the
> > > ConfigurationContext.
> > > hmm , as far as I know in a cluster all the replicates should be the
> > > same (so they need to have the same state) , so having different
> > > properties means different states.
> >
> >
> > The thing is, in our case, the ConfigurationContext may hold information
> > that is Node specific, and which should not be replicated.
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Rajith Attapattu <ra...@gmail.com>.
As Deepal points out, in a cluster u need an identical set of nodes.
Thats why at point Chamikara and I suggested loading all nodes from central
repo using URLBasedAxisConfigurator to ensure identical configuration.
Afkam, if there are nodes specific properties, then this application might
not be a good candiate for clustering.
As for Rampart and Sandesha, can these properties be made serializable?
Chamikara what are your thoughts on this?
Regards,
Rajith
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
>
>
>
> On 5/18/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
> >
> >
> >
> > Afkham Azeez wrote:
> > > We have a problem when it comes to replicating properties in our
> > > clustering implementation. There are some properties which are
> > > specific to a node, specially properties in the ConfigurationContext.
> > hmm , as far as I know in a cluster all the replicates should be the
> > same (so they need to have the same state) , so having different
> > properties means different states.
>
>
> The thing is, in our case, the ConfigurationContext may hold information
> that is Node specific, and which should not be replicated.
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
On 5/18/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
>
>
> Afkham Azeez wrote:
> > We have a problem when it comes to replicating properties in our
> > clustering implementation. There are some properties which are
> > specific to a node, specially properties in the ConfigurationContext.
> hmm , as far as I know in a cluster all the replicates should be the
> same (so they need to have the same state) , so having different
> properties means different states.
The thing is, in our case, the ConfigurationContext may hold information
that is Node specific, and which should not be replicated.
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Afkham Azeez wrote:
> We have a problem when it comes to replicating properties in our
> clustering implementation. There are some properties which are
> specific to a node, specially properties in the ConfigurationContext.
hmm , as far as I know in a cluster all the replicates should be the
same (so they need to have the same state) , so having different
properties means different states.
> Some properties are added by different modules such as Sandesha2,
> Rampart to the ConfigurationContext. One thing is that these objects
> are not serializable, and the other thing is that these properties
> should not be replicated. Some information which are specific to a
> node may be added to the ConfigurationContexts, and these should never
> be replicated.
>
> So there should be some way to inform Axis2 about the properties that
> need to be clustered and those that shouldn't be clustered.
>
> I suggest we introduce a new Map to AbstractContext called
> clusterableProperties. Stuff that are added to this Map will be
> replicated, and the service author/module author has to add the
> properties that need to be replicated into the clusterableProperties Map.
So go for it.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
If we use two property bags, the WS author has to be cluster aware, to make
a WS clusterable, he'd have to change many places.
-- Azeez
On 5/20/07, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
> Can we not use two property bags for this? MHO is this prefixes and
> suffixes may produce hard to debug bugs.
>
>
>
> -jaliya
>
> ----- Original Message -----
> *From:* Afkham Azeez <af...@gmail.com>
> *To:* axis-dev@ws.apache.org
> *Sent:* Saturday, May 19, 2007 8:48 AM
> *Subject:* Re: [Axis2] Clustering: Replicating properties in the context
> hierachy
>
> On second thoughts, lets make it a simple string not a regex. If we use
> regex, special characters (specially the period, which may be used
> regularly) have to be escaped by the user. To keep things simple, let's
> allow only prefixes, suffixes & exact matches;
>
> 1. Prefix - e.g. local_* ==> all properties beginning with the
> string "local_"
> 2. Suffix - e.g. *_local ==> all properties ending with the string
> "_local"
> 3. Exact match - e.g. Sandesha2PolicyBean
>
> -- Azeez
>
> On 5/19/07, Afkham Azeez <af...@gmail.com> wrote:
> >
> >
> >
> > On 5/18/07, Davanum Srinivas < davanum@gmail.com> wrote:
> > >
> > > Sounds good to me Azeez.
> > > - Should the name(s) be regexp expressions or just a simple "*" means
> > > (one or more characters)?
> >
> >
> > Let's make it regex. It will be easier to handle it with regex.
> >
> > - So is there a implicit <include name="*">? Should we allow folks to
> > > set includes as well (like in ant tasks). Guess it's an overkill.
> >
> >
> > I think there is no need to have an <includes />. Whatever which is not
> > explicitly excluded is included.
> >
> > thanks,
> > > dims
> > >
> > > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > > Great idea Dims.
> > > >
> > > > So under the ContextManager entry in the axis2.xml, we can specify
> > > the
> > > > patterns of the property name which have to be excluded from
> > > replication.
> > > > e.g.
> > > >
> > > > <ContextManager
> > > > class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> > > > ">
> > > > <Replication>
> > > > <Defaults>
> > > > <excludes name="foo.bar.*"/>
> > > > </Defaults>
> > > > <ConfigContextProperties>
> > > > <excludes name="my.sandesha.*"/>
> > > > ...
> > > > </ConfigContextProperties>
> > > > <ServiceGroupContextProperties>
> > > > <excludes name="..."/>
> > > > </ServiceGroupContextProperties>
> > > > <ServiceContextProperties>
> > > > <excludes name="..."/>
> > > > </ServiceContextProperties>
> > > > <Replication>
> > > > </ContextManager>
> > > >
> > > > So any of the context properties matching a particular property will
> > > not be
> > > > replicated.
> > > >
> > > > -- Azeez
> > > >
> > > >
> > > > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > > > >
> > > > > Only other thing i can think of is similar to you know the proxy
> > > > > settings...have regexp based includes and excludes (on the key) in
> > > the
> > > > > ClusterManager for the default properties we already have and
> > > allow
> > > > > API access (and/or axis2.xml entries) for folks to add/delete from
> > > the
> > > > > list of includes/excludes. that's that other extreme...
> > > > >
> > > > > -- dims
> > > > >
> > > > > On 5/18/07, Davanum Srinivas < davanum@gmail.com > wrote:
> > > > > > Azeez,
> > > > > >
> > > > > > Did you already rule out a simple solution? If a service author
> > > wants
> > > > > > a specific custom property to be available, then they can add a
> > > simple
> > > > > > prefix to the key in the Map?
> > > > > >
> > > > > > thanks,
> > > > > > dims
> > > > > >
> > > > > > On 5/18/07, Afkham Azeez < afkham@gmail.com > wrote:
> > > > > > > We have a problem when it comes to replicating properties in
> > > our
> > > > clustering
> > > > > > > implementation. There are some properties which are specific
> > > to a
> > > > node,
> > > > > > > specially properties in the ConfigurationContext. Some
> > > properties are
> > > > added
> > > > > > > by different modules such as Sandesha2, Rampart to the
> > > > ConfigurationContext.
> > > > > > > One thing is that these objects are not serializable, and the
> > > other
> > > > thing is
> > > > > > > that these properties should not be replicated. Some
> > > information which
> > > > are
> > > > > > > specific to a node may be added to the ConfigurationContexts,
> > > and
> > > > these
> > > > > > > should never be replicated.
> > > > > > >
> > > > > > > So there should be some way to inform Axis2 about the
> > > properties that
> > > > need
> > > > > > > to be clustered and those that shouldn't be clustered.
> > > > > > >
> > > > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > > > clusterableProperties. Stuff that are added to this Map will
> > > be
> > > > replicated,
> > > > > > > and the service author/module author has to add the properties
> > > that
> > > > need to
> > > > > > > be replicated into the clusterableProperties Map.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > --
> > > > > > > Thanks
> > > > > > > Afkham Azeez
> > > > > > >
> > > > > > > http://www.wso2.org
> > > > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> > > 0760
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > > >
> > > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > axis-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Thanks
> > > > Afkham Azeez
> > > >
> > > > http://www.wso2.org
> > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> >
> >
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
>
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Can we not use two property bags for this? MHO is this prefixes and suffixes may produce hard to debug bugs.
-jaliya
----- Original Message -----
From: Afkham Azeez
To: axis-dev@ws.apache.org
Sent: Saturday, May 19, 2007 8:48 AM
Subject: Re: [Axis2] Clustering: Replicating properties in the context hierachy
On second thoughts, lets make it a simple string not a regex. If we use regex, special characters (specially the period, which may be used regularly) have to be escaped by the user. To keep things simple, let's allow only prefixes, suffixes & exact matches;
1. Prefix - e.g. local_* ==> all properties beginning with the string "local_"
2. Suffix - e.g. *_local ==> all properties ending with the string "_local"
3. Exact match - e.g. Sandesha2PolicyBean
-- Azeez
On 5/19/07, Afkham Azeez <af...@gmail.com> wrote:
On 5/18/07, Davanum Srinivas < davanum@gmail.com> wrote:
Sounds good to me Azeez.
- Should the name(s) be regexp expressions or just a simple "*" means
(one or more characters)?
Let's make it regex. It will be easier to handle it with regex.
- So is there a implicit <include name="*">? Should we allow folks to
set includes as well (like in ant tasks). Guess it's an overkill.
I think there is no need to have an <includes />. Whatever which is not explicitly excluded is included.
thanks,
dims
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> Great idea Dims.
>
> So under the ContextManager entry in the axis2.xml, we can specify the
> patterns of the property name which have to be excluded from replication.
> e.g.
>
> <ContextManager
> class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> ">
> <Replication>
> <Defaults>
> <excludes name="foo.bar.*"/>
> </Defaults>
> <ConfigContextProperties>
> <excludes name="my.sandesha.*"/>
> ...
> </ConfigContextProperties>
> <ServiceGroupContextProperties>
> <excludes name="..."/>
> </ServiceGroupContextProperties>
> <ServiceContextProperties>
> <excludes name="..."/>
> </ServiceContextProperties>
> <Replication>
> </ContextManager>
>
> So any of the context properties matching a particular property will not be
> replicated.
>
> -- Azeez
>
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > Only other thing i can think of is similar to you know the proxy
> > settings...have regexp based includes and excludes (on the key) in the
> > ClusterManager for the default properties we already have and allow
> > API access (and/or axis2.xml entries) for folks to add/delete from the
> > list of includes/excludes. that's that other extreme...
> >
> > -- dims
> >
> > On 5/18/07, Davanum Srinivas < davanum@gmail.com > wrote:
> > > Azeez,
> > >
> > > Did you already rule out a simple solution? If a service author wants
> > > a specific custom property to be available, then they can add a simple
> > > prefix to the key in the Map?
> > >
> > > thanks,
> > > dims
> > >
> > > On 5/18/07, Afkham Azeez < afkham@gmail.com > wrote:
> > > > We have a problem when it comes to replicating properties in our
> clustering
> > > > implementation. There are some properties which are specific to a
> node,
> > > > specially properties in the ConfigurationContext. Some properties are
> added
> > > > by different modules such as Sandesha2, Rampart to the
> ConfigurationContext.
> > > > One thing is that these objects are not serializable, and the other
> thing is
> > > > that these properties should not be replicated. Some information which
> are
> > > > specific to a node may be added to the ConfigurationContexts, and
> these
> > > > should never be replicated.
> > > >
> > > > So there should be some way to inform Axis2 about the properties that
> need
> > > > to be clustered and those that shouldn't be clustered.
> > > >
> > > > I suggest we introduce a new Map to AbstractContext called
> > > > clusterableProperties. Stuff that are added to this Map will be
> replicated,
> > > > and the service author/module author has to add the properties that
> need to
> > > > be replicated into the clusterableProperties Map.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Thanks
> > > > Afkham Azeez
> > > >
> > > > http://www.wso2.org
> > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
>
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Davanum Srinivas :: http://davanum.wordpress.com
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
On second thoughts, lets make it a simple string not a regex. If we use
regex, special characters (specially the period, which may be used
regularly) have to be escaped by the user. To keep things simple, let's
allow only prefixes, suffixes & exact matches;
1. Prefix - e.g. local_* ==> all properties beginning with the string
"local_"
2. Suffix - e.g. *_local ==> all properties ending with the string
"_local"
3. Exact match - e.g. Sandesha2PolicyBean
-- Azeez
On 5/19/07, Afkham Azeez <af...@gmail.com> wrote:
>
>
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > Sounds good to me Azeez.
> > - Should the name(s) be regexp expressions or just a simple "*" means
> > (one or more characters)?
>
>
> Let's make it regex. It will be easier to handle it with regex.
>
> - So is there a implicit <include name="*">? Should we allow folks to
> > set includes as well (like in ant tasks). Guess it's an overkill.
>
>
> I think there is no need to have an <includes />. Whatever which is not
> explicitly excluded is included.
>
> thanks,
> > dims
> >
> > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > Great idea Dims.
> > >
> > > So under the ContextManager entry in the axis2.xml, we can specify the
> >
> > > patterns of the property name which have to be excluded from
> > replication.
> > > e.g.
> > >
> > > <ContextManager
> > > class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> > > ">
> > > <Replication>
> > > <Defaults>
> > > <excludes name="foo.bar.*"/>
> > > </Defaults>
> > > <ConfigContextProperties>
> > > <excludes name="my.sandesha.*"/>
> > > ...
> > > </ConfigContextProperties>
> > > <ServiceGroupContextProperties>
> > > <excludes name="..."/>
> > > </ServiceGroupContextProperties>
> > > <ServiceContextProperties>
> > > <excludes name="..."/>
> > > </ServiceContextProperties>
> > > <Replication>
> > > </ContextManager>
> > >
> > > So any of the context properties matching a particular property will
> > not be
> > > replicated.
> > >
> > > -- Azeez
> > >
> > >
> > > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > > >
> > > > Only other thing i can think of is similar to you know the proxy
> > > > settings...have regexp based includes and excludes (on the key) in
> > the
> > > > ClusterManager for the default properties we already have and allow
> > > > API access (and/or axis2.xml entries) for folks to add/delete from
> > the
> > > > list of includes/excludes. that's that other extreme...
> > > >
> > > > -- dims
> > > >
> > > > On 5/18/07, Davanum Srinivas <davanum@gmail.com > wrote:
> > > > > Azeez,
> > > > >
> > > > > Did you already rule out a simple solution? If a service author
> > wants
> > > > > a specific custom property to be available, then they can add a
> > simple
> > > > > prefix to the key in the Map?
> > > > >
> > > > > thanks,
> > > > > dims
> > > > >
> > > > > On 5/18/07, Afkham Azeez < afkham@gmail.com > wrote:
> > > > > > We have a problem when it comes to replicating properties in our
> > > clustering
> > > > > > implementation. There are some properties which are specific to
> > a
> > > node,
> > > > > > specially properties in the ConfigurationContext. Some
> > properties are
> > > added
> > > > > > by different modules such as Sandesha2, Rampart to the
> > > ConfigurationContext.
> > > > > > One thing is that these objects are not serializable, and the
> > other
> > > thing is
> > > > > > that these properties should not be replicated. Some information
> > which
> > > are
> > > > > > specific to a node may be added to the ConfigurationContexts,
> > and
> > > these
> > > > > > should never be replicated.
> > > > > >
> > > > > > So there should be some way to inform Axis2 about the properties
> > that
> > > need
> > > > > > to be clustered and those that shouldn't be clustered.
> > > > > >
> > > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > > clusterableProperties. Stuff that are added to this Map will be
> > > replicated,
> > > > > > and the service author/module author has to add the properties
> > that
> > > need to
> > > > > > be replicated into the clusterableProperties Map.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > --
> > > > > > Thanks
> > > > > > Afkham Azeez
> > > > > >
> > > > > > http://www.wso2.org
> > > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> > 0760
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > > >
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Thanks
> > > Afkham Azeez
> > >
> > > http://www.wso2.org
> > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
>
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
>
> Sounds good to me Azeez.
> - Should the name(s) be regexp expressions or just a simple "*" means
> (one or more characters)?
Let's make it regex. It will be easier to handle it with regex.
- So is there a implicit <include name="*">? Should we allow folks to
> set includes as well (like in ant tasks). Guess it's an overkill.
I think there is no need to have an <includes />. Whatever which is not
explicitly excluded is included.
thanks,
> dims
>
> On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > Great idea Dims.
> >
> > So under the ContextManager entry in the axis2.xml, we can specify the
> > patterns of the property name which have to be excluded from
> replication.
> > e.g.
> >
> > <ContextManager
> > class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> > ">
> > <Replication>
> > <Defaults>
> > <excludes name="foo.bar.*"/>
> > </Defaults>
> > <ConfigContextProperties>
> > <excludes name="my.sandesha.*"/>
> > ...
> > </ConfigContextProperties>
> > <ServiceGroupContextProperties>
> > <excludes name="..."/>
> > </ServiceGroupContextProperties>
> > <ServiceContextProperties>
> > <excludes name="..."/>
> > </ServiceContextProperties>
> > <Replication>
> > </ContextManager>
> >
> > So any of the context properties matching a particular property will not
> be
> > replicated.
> >
> > -- Azeez
> >
> >
> > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > >
> > > Only other thing i can think of is similar to you know the proxy
> > > settings...have regexp based includes and excludes (on the key) in the
> > > ClusterManager for the default properties we already have and allow
> > > API access (and/or axis2.xml entries) for folks to add/delete from the
> > > list of includes/excludes. that's that other extreme...
> > >
> > > -- dims
> > >
> > > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > > > Azeez,
> > > >
> > > > Did you already rule out a simple solution? If a service author
> wants
> > > > a specific custom property to be available, then they can add a
> simple
> > > > prefix to the key in the Map?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 5/18/07, Afkham Azeez < afkham@gmail.com> wrote:
> > > > > We have a problem when it comes to replicating properties in our
> > clustering
> > > > > implementation. There are some properties which are specific to a
> > node,
> > > > > specially properties in the ConfigurationContext. Some properties
> are
> > added
> > > > > by different modules such as Sandesha2, Rampart to the
> > ConfigurationContext.
> > > > > One thing is that these objects are not serializable, and the
> other
> > thing is
> > > > > that these properties should not be replicated. Some information
> which
> > are
> > > > > specific to a node may be added to the ConfigurationContexts, and
> > these
> > > > > should never be replicated.
> > > > >
> > > > > So there should be some way to inform Axis2 about the properties
> that
> > need
> > > > > to be clustered and those that shouldn't be clustered.
> > > > >
> > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > clusterableProperties. Stuff that are added to this Map will be
> > replicated,
> > > > > and the service author/module author has to add the properties
> that
> > need to
> > > > > be replicated into the clusterableProperties Map.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Thanks
> > > > > Afkham Azeez
> > > > >
> > > > > http://www.wso2.org
> > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> 0760
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> >
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Guys,
Sorry about joining to the conversation late.
I also agree to the point that there could be Node specific properties but
dont think it's good to change the Axis2 property handling interface (this
will look bad in the non-clustered case). Expression based solution seems to
be good. +1 for that.
' "*" means (one or more characters)' looks good enough for me.
Chamikara
On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
>
> Sounds good to me Azeez.
> - Should the name(s) be regexp expressions or just a simple "*" means
> (one or more characters)?
> - So is there a implicit <include name="*">? Should we allow folks to
> set includes as well (like in ant tasks). Guess it's an overkill.
>
> thanks,
> dims
>
> On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > Great idea Dims.
> >
> > So under the ContextManager entry in the axis2.xml, we can specify the
> > patterns of the property name which have to be excluded from
> replication.
> > e.g.
> >
> > <ContextManager
> > class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> > ">
> > <Replication>
> > <Defaults>
> > <excludes name="foo.bar.*"/>
> > </Defaults>
> > <ConfigContextProperties>
> > <excludes name="my.sandesha.*"/>
> > ...
> > </ConfigContextProperties>
> > <ServiceGroupContextProperties>
> > <excludes name="..."/>
> > </ServiceGroupContextProperties>
> > <ServiceContextProperties>
> > <excludes name="..."/>
> > </ServiceContextProperties>
> > <Replication>
> > </ContextManager>
> >
> > So any of the context properties matching a particular property will not
> be
> > replicated.
> >
> > -- Azeez
> >
> >
> > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > >
> > > Only other thing i can think of is similar to you know the proxy
> > > settings...have regexp based includes and excludes (on the key) in the
> > > ClusterManager for the default properties we already have and allow
> > > API access (and/or axis2.xml entries) for folks to add/delete from the
> > > list of includes/excludes. that's that other extreme...
> > >
> > > -- dims
> > >
> > > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > > > Azeez,
> > > >
> > > > Did you already rule out a simple solution? If a service author
> wants
> > > > a specific custom property to be available, then they can add a
> simple
> > > > prefix to the key in the Map?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 5/18/07, Afkham Azeez < afkham@gmail.com> wrote:
> > > > > We have a problem when it comes to replicating properties in our
> > clustering
> > > > > implementation. There are some properties which are specific to a
> > node,
> > > > > specially properties in the ConfigurationContext. Some properties
> are
> > added
> > > > > by different modules such as Sandesha2, Rampart to the
> > ConfigurationContext.
> > > > > One thing is that these objects are not serializable, and the
> other
> > thing is
> > > > > that these properties should not be replicated. Some information
> which
> > are
> > > > > specific to a node may be added to the ConfigurationContexts, and
> > these
> > > > > should never be replicated.
> > > > >
> > > > > So there should be some way to inform Axis2 about the properties
> that
> > need
> > > > > to be clustered and those that shouldn't be clustered.
> > > > >
> > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > clusterableProperties. Stuff that are added to this Map will be
> > replicated,
> > > > > and the service author/module author has to add the properties
> that
> > need to
> > > > > be replicated into the clusterableProperties Map.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Thanks
> > > > > Afkham Azeez
> > > > >
> > > > > http://www.wso2.org
> > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> 0760
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> >
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Chamikara Jayalath
WSO2 Inc.
http://wso2.com/
http://wso2.org/ - For your Oxygen needs
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Davanum Srinivas <da...@gmail.com>.
Sounds good to me Azeez.
- Should the name(s) be regexp expressions or just a simple "*" means
(one or more characters)?
- So is there a implicit <include name="*">? Should we allow folks to
set includes as well (like in ant tasks). Guess it's an overkill.
thanks,
dims
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> Great idea Dims.
>
> So under the ContextManager entry in the axis2.xml, we can specify the
> patterns of the property name which have to be excluded from replication.
> e.g.
>
> <ContextManager
> class="org.apache.axis2.cluster.tribes.context.TribesContextManager
> ">
> <Replication>
> <Defaults>
> <excludes name="foo.bar.*"/>
> </Defaults>
> <ConfigContextProperties>
> <excludes name="my.sandesha.*"/>
> ...
> </ConfigContextProperties>
> <ServiceGroupContextProperties>
> <excludes name="..."/>
> </ServiceGroupContextProperties>
> <ServiceContextProperties>
> <excludes name="..."/>
> </ServiceContextProperties>
> <Replication>
> </ContextManager>
>
> So any of the context properties matching a particular property will not be
> replicated.
>
> -- Azeez
>
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > Only other thing i can think of is similar to you know the proxy
> > settings...have regexp based includes and excludes (on the key) in the
> > ClusterManager for the default properties we already have and allow
> > API access (and/or axis2.xml entries) for folks to add/delete from the
> > list of includes/excludes. that's that other extreme...
> >
> > -- dims
> >
> > On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > > Azeez,
> > >
> > > Did you already rule out a simple solution? If a service author wants
> > > a specific custom property to be available, then they can add a simple
> > > prefix to the key in the Map?
> > >
> > > thanks,
> > > dims
> > >
> > > On 5/18/07, Afkham Azeez < afkham@gmail.com> wrote:
> > > > We have a problem when it comes to replicating properties in our
> clustering
> > > > implementation. There are some properties which are specific to a
> node,
> > > > specially properties in the ConfigurationContext. Some properties are
> added
> > > > by different modules such as Sandesha2, Rampart to the
> ConfigurationContext.
> > > > One thing is that these objects are not serializable, and the other
> thing is
> > > > that these properties should not be replicated. Some information which
> are
> > > > specific to a node may be added to the ConfigurationContexts, and
> these
> > > > should never be replicated.
> > > >
> > > > So there should be some way to inform Axis2 about the properties that
> need
> > > > to be clustered and those that shouldn't be clustered.
> > > >
> > > > I suggest we introduce a new Map to AbstractContext called
> > > > clusterableProperties. Stuff that are added to this Map will be
> replicated,
> > > > and the service author/module author has to add the properties that
> need to
> > > > be replicated into the clusterableProperties Map.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Thanks
> > > > Afkham Azeez
> > > >
> > > > http://www.wso2.org
> > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
>
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
Great idea Dims.
So under the ContextManager entry in the axis2.xml, we can specify the
patterns of the property name which have to be excluded from replication.
e.g.
<ContextManager class="
org.apache.axis2.cluster.tribes.context.TribesContextManager">
<Replication>
<Defaults>
<excludes name="foo.bar.*"/>
</Defaults>
<ConfigContextProperties>
<excludes name="my.sandesha.*"/>
...
</ConfigContextProperties>
<ServiceGroupContextProperties>
<excludes name="..."/>
</ServiceGroupContextProperties>
<ServiceContextProperties>
<excludes name="..."/>
</ServiceContextProperties>
<Replication>
</ContextManager>
So any of the context properties matching a particular property will not be
replicated.
-- Azeez
On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
>
> Only other thing i can think of is similar to you know the proxy
> settings...have regexp based includes and excludes (on the key) in the
> ClusterManager for the default properties we already have and allow
> API access (and/or axis2.xml entries) for folks to add/delete from the
> list of includes/excludes. that's that other extreme...
>
> -- dims
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > Azeez,
> >
> > Did you already rule out a simple solution? If a service author wants
> > a specific custom property to be available, then they can add a simple
> > prefix to the key in the Map?
> >
> > thanks,
> > dims
> >
> > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > We have a problem when it comes to replicating properties in our
> clustering
> > > implementation. There are some properties which are specific to a
> node,
> > > specially properties in the ConfigurationContext. Some properties are
> added
> > > by different modules such as Sandesha2, Rampart to the
> ConfigurationContext.
> > > One thing is that these objects are not serializable, and the other
> thing is
> > > that these properties should not be replicated. Some information which
> are
> > > specific to a node may be added to the ConfigurationContexts, and
> these
> > > should never be replicated.
> > >
> > > So there should be some way to inform Axis2 about the properties that
> need
> > > to be clustered and those that shouldn't be clustered.
> > >
> > > I suggest we introduce a new Map to AbstractContext called
> > > clusterableProperties. Stuff that are added to this Map will be
> replicated,
> > > and the service author/module author has to add the properties that
> need to
> > > be replicated into the clusterableProperties Map.
> > >
> > > Thoughts?
> > >
> > > --
> > > Thanks
> > > Afkham Azeez
> > >
> > > http://www.wso2.org
> > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
Definitely. +1.
-- Azeez
On 5/19/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> We then need to document this for all module authors to follow ..
> otherwise someone else can write a module and now the clustering will fail
> because the clustering config didn't know the patters that module author
> used and hence didn't exclude it.
>
> Sanjiva.
>
>
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
We then need to document this for all module authors to follow ..
otherwise someone else can write a module and now the clustering will fail
because the clustering config didn't know the patters that module author
used and hence didn't exclude it.
Sanjiva.
Rajith Attapattu wrote:
> Oh I see, I was thinking node specific state.
> Yes things like IP address, working address etc can be marked with some
> prefix like _local and then weed out using filters.
>
> Rajith
>
> On 5/18/07, *Afkham Azeez* <afkham@gmail.com <ma...@gmail.com>>
> wrote:
>
> Generally, in the clustered scenario, all nodes will share the same
> URL repo. Nodes may store node specifi information e.g. working
> directory, local IP address etc. Nobody can impose restrictions
> saying that node specific data cannot be maintained.
>
> Azeez
>
> On 5/18/07, *Rajith Attapattu* < rajith77@gmail.com
> <ma...@gmail.com>> wrote:
>
> Dims, Afkam,
>
> Dims suggestion is good. I agree that there can be static data
> that comes from configuration and doesn't need to be replicated.
> So weedng them out is useful.
> However having node specific data is still not a good idea IMO
> (even though u can weed them out from replication using Dims idea).
> One example given by Chamikara is node specific policies from
> sandesha policy bean. I think u need identical policies (and
> other data) for replicas in a cluster.
> Afkam can u provide some examples for node specific proeprties ?
> (Maybe I didn't understand your point)
>
> Regards,
>
> Rajith
>
>
> On 5/18/07, *Davanum Srinivas* < davanum@gmail.com
> <ma...@gmail.com>> wrote:
>
> Only other thing i can think of is similar to you know the proxy
> settings...have regexp based includes and excludes (on the
> key) in the
> ClusterManager for the default properties we already have
> and allow
> API access (and/or axis2.xml entries) for folks to
> add/delete from the
> list of includes/excludes. that's that other extreme...
>
> -- dims
>
> On 5/18/07, Davanum Srinivas < davanum@gmail.com
> <ma...@gmail.com>> wrote:
> > Azeez,
> >
> > Did you already rule out a simple solution? If a service
> author wants
> > a specific custom property to be available, then they can
> add a simple
> > prefix to the key in the Map?
> >
> > thanks,
> > dims
> >
> > On 5/18/07, Afkham Azeez <afkham@gmail.com
> <ma...@gmail.com>> wrote:
> > > We have a problem when it comes to replicating
> properties in our clustering
> > > implementation. There are some properties which are
> specific to a node,
> > > specially properties in the ConfigurationContext. Some
> properties are added
> > > by different modules such as Sandesha2, Rampart to the
> ConfigurationContext.
> > > One thing is that these objects are not serializable,
> and the other thing is
> > > that these properties should not be replicated. Some
> information which are
> > > specific to a node may be added to the
> ConfigurationContexts, and these
> > > should never be replicated.
> > >
> > > So there should be some way to inform Axis2 about the
> properties that need
> > > to be clustered and those that shouldn't be clustered.
> > >
> > > I suggest we introduce a new Map to AbstractContext called
> > > clusterableProperties. Stuff that are added to this Map
> will be replicated,
> > > and the service author/module author has to add the
> properties that need to
> > > be replicated into the clusterableProperties Map.
> > >
> > > Thoughts?
> > >
> > > --
> > > Thanks
> > > Afkham Azeez
> > >
> > > http://www.wso2.org
> > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2
> C887 665E 0760
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> <http://davanum.wordpress.com>
> >
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
> --
>
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Rajith Attapattu <ra...@gmail.com>.
Oh I see, I was thinking node specific state.
Yes things like IP address, working address etc can be marked with some
prefix like _local and then weed out using filters.
Rajith
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
>
> Generally, in the clustered scenario, all nodes will share the same URL
> repo. Nodes may store node specifi information e.g. working directory,
> local IP address etc. Nobody can impose restrictions saying that node
> specific data cannot be maintained.
>
> Azeez
>
> On 5/18/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> > Dims, Afkam,
> >
> > Dims suggestion is good. I agree that there can be static data that
> > comes from configuration and doesn't need to be replicated.
> > So weedng them out is useful.
> > However having node specific data is still not a good idea IMO (even
> > though u can weed them out from replication using Dims idea).
> > One example given by Chamikara is node specific policies from sandesha
> > policy bean. I think u need identical policies (and other data) for replicas
> > in a cluster.
> > Afkam can u provide some examples for node specific proeprties ? (Maybe
> > I didn't understand your point)
> >
> > Regards,
> >
> > Rajith
> >
> > On 5/18/07, Davanum Srinivas < davanum@gmail.com> wrote:
> > >
> > > Only other thing i can think of is similar to you know the proxy
> > > settings...have regexp based includes and excludes (on the key) in the
> > > ClusterManager for the default properties we already have and allow
> > > API access (and/or axis2.xml entries) for folks to add/delete from the
> > > list of includes/excludes. that's that other extreme...
> > >
> > > -- dims
> > >
> > > On 5/18/07, Davanum Srinivas < davanum@gmail.com > wrote:
> > > > Azeez,
> > > >
> > > > Did you already rule out a simple solution? If a service author
> > > wants
> > > > a specific custom property to be available, then they can add a
> > > simple
> > > > prefix to the key in the Map?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > > > We have a problem when it comes to replicating properties in our
> > > clustering
> > > > > implementation. There are some properties which are specific to a
> > > node,
> > > > > specially properties in the ConfigurationContext. Some properties
> > > are added
> > > > > by different modules such as Sandesha2, Rampart to the
> > > ConfigurationContext.
> > > > > One thing is that these objects are not serializable, and the
> > > other thing is
> > > > > that these properties should not be replicated. Some information
> > > which are
> > > > > specific to a node may be added to the ConfigurationContexts, and
> > > these
> > > > > should never be replicated.
> > > > >
> > > > > So there should be some way to inform Axis2 about the properties
> > > that need
> > > > > to be clustered and those that shouldn't be clustered.
> > > > >
> > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > clusterableProperties. Stuff that are added to this Map will be
> > > replicated,
> > > > > and the service author/module author has to add the properties
> > > that need to
> > > > > be replicated into the clusterableProperties Map.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Thanks
> > > > > Afkham Azeez
> > > > >
> > > > > http://www.wso2.org
> > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> > > 0760
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
What I meant was, since the URL repo will be used, there is no need to
replicate Sandesha policy beans etc.
-- Azeez
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
>
> Generally, in the clustered scenario, all nodes will share the same URL
> repo. Nodes may store node specifi information e.g. working directory,
> local IP address etc. Nobody can impose restrictions saying that node
> specific data cannot be maintained.
>
> Azeez
>
> On 5/18/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> > Dims, Afkam,
> >
> > Dims suggestion is good. I agree that there can be static data that
> > comes from configuration and doesn't need to be replicated.
> > So weedng them out is useful.
> > However having node specific data is still not a good idea IMO (even
> > though u can weed them out from replication using Dims idea).
> > One example given by Chamikara is node specific policies from sandesha
> > policy bean. I think u need identical policies (and other data) for replicas
> > in a cluster.
> > Afkam can u provide some examples for node specific proeprties ? (Maybe
> > I didn't understand your point)
> >
> > Regards,
> >
> > Rajith
> >
> > On 5/18/07, Davanum Srinivas < davanum@gmail.com> wrote:
> > >
> > > Only other thing i can think of is similar to you know the proxy
> > > settings...have regexp based includes and excludes (on the key) in the
> > > ClusterManager for the default properties we already have and allow
> > > API access (and/or axis2.xml entries) for folks to add/delete from the
> > > list of includes/excludes. that's that other extreme...
> > >
> > > -- dims
> > >
> > > On 5/18/07, Davanum Srinivas < davanum@gmail.com > wrote:
> > > > Azeez,
> > > >
> > > > Did you already rule out a simple solution? If a service author
> > > wants
> > > > a specific custom property to be available, then they can add a
> > > simple
> > > > prefix to the key in the Map?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > > > We have a problem when it comes to replicating properties in our
> > > clustering
> > > > > implementation. There are some properties which are specific to a
> > > node,
> > > > > specially properties in the ConfigurationContext. Some properties
> > > are added
> > > > > by different modules such as Sandesha2, Rampart to the
> > > ConfigurationContext.
> > > > > One thing is that these objects are not serializable, and the
> > > other thing is
> > > > > that these properties should not be replicated. Some information
> > > which are
> > > > > specific to a node may be added to the ConfigurationContexts, and
> > > these
> > > > > should never be replicated.
> > > > >
> > > > > So there should be some way to inform Axis2 about the properties
> > > that need
> > > > > to be clustered and those that shouldn't be clustered.
> > > > >
> > > > > I suggest we introduce a new Map to AbstractContext called
> > > > > clusterableProperties. Stuff that are added to this Map will be
> > > replicated,
> > > > > and the service author/module author has to add the properties
> > > that need to
> > > > > be replicated into the clusterableProperties Map.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Thanks
> > > > > Afkham Azeez
> > > > >
> > > > > http://www.wso2.org
> > > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> > > 0760
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas :: http://davanum.wordpress.com
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Afkham Azeez <af...@gmail.com>.
Generally, in the clustered scenario, all nodes will share the same URL
repo. Nodes may store node specifi information e.g. working directory, local
IP address etc. Nobody can impose restrictions saying that node specific
data cannot be maintained.
Azeez
On 5/18/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Dims, Afkam,
>
> Dims suggestion is good. I agree that there can be static data that comes
> from configuration and doesn't need to be replicated.
> So weedng them out is useful.
> However having node specific data is still not a good idea IMO (even
> though u can weed them out from replication using Dims idea).
> One example given by Chamikara is node specific policies from sandesha
> policy bean. I think u need identical policies (and other data) for replicas
> in a cluster.
> Afkam can u provide some examples for node specific proeprties ? (Maybe I
> didn't understand your point)
>
> Regards,
>
> Rajith
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > Only other thing i can think of is similar to you know the proxy
> > settings...have regexp based includes and excludes (on the key) in the
> > ClusterManager for the default properties we already have and allow
> > API access (and/or axis2.xml entries) for folks to add/delete from the
> > list of includes/excludes. that's that other extreme...
> >
> > -- dims
> >
> > On 5/18/07, Davanum Srinivas <davanum@gmail.com > wrote:
> > > Azeez,
> > >
> > > Did you already rule out a simple solution? If a service author wants
> > > a specific custom property to be available, then they can add a simple
> > > prefix to the key in the Map?
> > >
> > > thanks,
> > > dims
> > >
> > > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > > We have a problem when it comes to replicating properties in our
> > clustering
> > > > implementation. There are some properties which are specific to a
> > node,
> > > > specially properties in the ConfigurationContext. Some properties
> > are added
> > > > by different modules such as Sandesha2, Rampart to the
> > ConfigurationContext.
> > > > One thing is that these objects are not serializable, and the other
> > thing is
> > > > that these properties should not be replicated. Some information
> > which are
> > > > specific to a node may be added to the ConfigurationContexts, and
> > these
> > > > should never be replicated.
> > > >
> > > > So there should be some way to inform Axis2 about the properties
> > that need
> > > > to be clustered and those that shouldn't be clustered.
> > > >
> > > > I suggest we introduce a new Map to AbstractContext called
> > > > clusterableProperties. Stuff that are added to this Map will be
> > replicated,
> > > > and the service author/module author has to add the properties that
> > need to
> > > > be replicated into the clusterableProperties Map.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Thanks
> > > > Afkham Azeez
> > > >
> > > > http://www.wso2.org
> > > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Rajith Attapattu <ra...@gmail.com>.
Dims, Afkam,
Dims suggestion is good. I agree that there can be static data that comes
from configuration and doesn't need to be replicated.
So weedng them out is useful.
However having node specific data is still not a good idea IMO (even though
u can weed them out from replication using Dims idea).
One example given by Chamikara is node specific policies from sandesha
policy bean. I think u need identical policies (and other data) for replicas
in a cluster.
Afkam can u provide some examples for node specific proeprties ? (Maybe I
didn't understand your point)
Regards,
Rajith
On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
>
> Only other thing i can think of is similar to you know the proxy
> settings...have regexp based includes and excludes (on the key) in the
> ClusterManager for the default properties we already have and allow
> API access (and/or axis2.xml entries) for folks to add/delete from the
> list of includes/excludes. that's that other extreme...
>
> -- dims
>
> On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> > Azeez,
> >
> > Did you already rule out a simple solution? If a service author wants
> > a specific custom property to be available, then they can add a simple
> > prefix to the key in the Map?
> >
> > thanks,
> > dims
> >
> > On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > > We have a problem when it comes to replicating properties in our
> clustering
> > > implementation. There are some properties which are specific to a
> node,
> > > specially properties in the ConfigurationContext. Some properties are
> added
> > > by different modules such as Sandesha2, Rampart to the
> ConfigurationContext.
> > > One thing is that these objects are not serializable, and the other
> thing is
> > > that these properties should not be replicated. Some information which
> are
> > > specific to a node may be added to the ConfigurationContexts, and
> these
> > > should never be replicated.
> > >
> > > So there should be some way to inform Axis2 about the properties that
> need
> > > to be clustered and those that shouldn't be clustered.
> > >
> > > I suggest we introduce a new Map to AbstractContext called
> > > clusterableProperties. Stuff that are added to this Map will be
> replicated,
> > > and the service author/module author has to add the properties that
> need to
> > > be replicated into the clusterableProperties Map.
> > >
> > > Thoughts?
> > >
> > > --
> > > Thanks
> > > Afkham Azeez
> > >
> > > http://www.wso2.org
> > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Davanum Srinivas <da...@gmail.com>.
Only other thing i can think of is similar to you know the proxy
settings...have regexp based includes and excludes (on the key) in the
ClusterManager for the default properties we already have and allow
API access (and/or axis2.xml entries) for folks to add/delete from the
list of includes/excludes. that's that other extreme...
-- dims
On 5/18/07, Davanum Srinivas <da...@gmail.com> wrote:
> Azeez,
>
> Did you already rule out a simple solution? If a service author wants
> a specific custom property to be available, then they can add a simple
> prefix to the key in the Map?
>
> thanks,
> dims
>
> On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> > We have a problem when it comes to replicating properties in our clustering
> > implementation. There are some properties which are specific to a node,
> > specially properties in the ConfigurationContext. Some properties are added
> > by different modules such as Sandesha2, Rampart to the ConfigurationContext.
> > One thing is that these objects are not serializable, and the other thing is
> > that these properties should not be replicated. Some information which are
> > specific to a node may be added to the ConfigurationContexts, and these
> > should never be replicated.
> >
> > So there should be some way to inform Axis2 about the properties that need
> > to be clustered and those that shouldn't be clustered.
> >
> > I suggest we introduce a new Map to AbstractContext called
> > clusterableProperties. Stuff that are added to this Map will be replicated,
> > and the service author/module author has to add the properties that need to
> > be replicated into the clusterableProperties Map.
> >
> > Thoughts?
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Davanum Srinivas <da...@gmail.com>.
Azeez,
Did you already rule out a simple solution? If a service author wants
a specific custom property to be available, then they can add a simple
prefix to the key in the Map?
thanks,
dims
On 5/18/07, Afkham Azeez <af...@gmail.com> wrote:
> We have a problem when it comes to replicating properties in our clustering
> implementation. There are some properties which are specific to a node,
> specially properties in the ConfigurationContext. Some properties are added
> by different modules such as Sandesha2, Rampart to the ConfigurationContext.
> One thing is that these objects are not serializable, and the other thing is
> that these properties should not be replicated. Some information which are
> specific to a node may be added to the ConfigurationContexts, and these
> should never be replicated.
>
> So there should be some way to inform Axis2 about the properties that need
> to be clustered and those that shouldn't be clustered.
>
> I suggest we introduce a new Map to AbstractContext called
> clusterableProperties. Stuff that are added to this Map will be replicated,
> and the service author/module author has to add the properties that need to
> be replicated into the clusterableProperties Map.
>
> Thoughts?
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by David Illsley <da...@gmail.com>.
I'm not against the idea of having multiple bags in principle, but I'd
want to make sure that they could be used for reasons other than
clustering - I don't care about clustering but do about context
serialization and another use-case to do with instance independent
properties.
David
On 21/05/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Thiking along these lines .. what if we introduce a bag at configcontext
> level for module authors to store non-clusterable properties? That's the
> real usecase we're trying to handle right?
>
> That way normal service authors are not affected and need to only know
> that if they want their stuff clustering correctly then anything they put
> into the context hierarchy must be serializable. Module authors need to be
> more aware of the world .. which IMO is absolutely fine.
>
> Sanjiva.
>
> Eran Chinthaka wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > Sorry for getting late in to this discussion. I have a very fundamental
> > question on this.
> >
> > I assume that Axis2 clustering implementation is to have distributed
> > SOAP processing nodes.
> >
> > If that is the case, Azeez why are you suggesting not to replicate all
> > the properties inside config context? We all agree that config context
> > holds system properties. If one node adds something to config context,
> > that should better be communicated/replicated to other nodes in the system.
> > What I feel is if you want to have a set of private properties then
> > those should not be inserted to config context. One option is to have a
> > context only for that node, but having different rules for naming the
> > properties to differentiate them seems not to be a clean idea, in a
> > distributed system.
> > The replication manager or whoever handles these communications should
> > not know about those rules. It should simply make sure all the nodes
> > have the same environment.
> >
> > So IMHO, the best option is to have something like a NodeContext to have
> > those properties.
> >
> > BTW, if I am off-topic, please discard this email ;)
> >
> > Chinthaka
> >
> >
> > Afkham Azeez wrote:
> >> We have a problem when it comes to replicating properties in our
> >> clustering implementation. There are some properties which are specific
> >> to a node, specially properties in the ConfigurationContext. Some
> >> properties are added by different modules such as Sandesha2, Rampart to
> >> the ConfigurationContext. One thing is that these objects are not
> >> serializable, and the other thing is that these properties should not be
> >> replicated. Some information which are specific to a node may be added
> >> to the ConfigurationContexts, and these should never be replicated.
> >>
> >> So there should be some way to inform Axis2 about the properties that
> >> need to be clustered and those that shouldn't be clustered.
> >>
> >> I suggest we introduce a new Map to AbstractContext called
> >> clusterableProperties. Stuff that are added to this Map will be
> >> replicated, and the service author/module author has to add the
> >> properties that need to be replicated into the clusterableProperties Map.
> >>
> >> Thoughts?
> >>
> >> --
> >> Thanks
> >> Afkham Azeez
> >>
> >> http://www.wso2.org
> >> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGURDCjON2uBzUhh8RAgXwAJ4wfLfiihBpliOqmE6mPwMP0J/gUwCgtDnN
> > dOd7zIJFfr2F0SJagu233q4=
> > =xt9t
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Thiking along these lines .. what if we introduce a bag at configcontext
level for module authors to store non-clusterable properties? That's the
real usecase we're trying to handle right?
That way normal service authors are not affected and need to only know
that if they want their stuff clustering correctly then anything they put
into the context hierarchy must be serializable. Module authors need to be
more aware of the world .. which IMO is absolutely fine.
Sanjiva.
Eran Chinthaka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Sorry for getting late in to this discussion. I have a very fundamental
> question on this.
>
> I assume that Axis2 clustering implementation is to have distributed
> SOAP processing nodes.
>
> If that is the case, Azeez why are you suggesting not to replicate all
> the properties inside config context? We all agree that config context
> holds system properties. If one node adds something to config context,
> that should better be communicated/replicated to other nodes in the system.
> What I feel is if you want to have a set of private properties then
> those should not be inserted to config context. One option is to have a
> context only for that node, but having different rules for naming the
> properties to differentiate them seems not to be a clean idea, in a
> distributed system.
> The replication manager or whoever handles these communications should
> not know about those rules. It should simply make sure all the nodes
> have the same environment.
>
> So IMHO, the best option is to have something like a NodeContext to have
> those properties.
>
> BTW, if I am off-topic, please discard this email ;)
>
> Chinthaka
>
>
> Afkham Azeez wrote:
>> We have a problem when it comes to replicating properties in our
>> clustering implementation. There are some properties which are specific
>> to a node, specially properties in the ConfigurationContext. Some
>> properties are added by different modules such as Sandesha2, Rampart to
>> the ConfigurationContext. One thing is that these objects are not
>> serializable, and the other thing is that these properties should not be
>> replicated. Some information which are specific to a node may be added
>> to the ConfigurationContexts, and these should never be replicated.
>>
>> So there should be some way to inform Axis2 about the properties that
>> need to be clustered and those that shouldn't be clustered.
>>
>> I suggest we introduce a new Map to AbstractContext called
>> clusterableProperties. Stuff that are added to this Map will be
>> replicated, and the service author/module author has to add the
>> properties that need to be replicated into the clusterableProperties Map.
>>
>> Thoughts?
>>
>> --
>> Thanks
>> Afkham Azeez
>>
>> http://www.wso2.org
>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGURDCjON2uBzUhh8RAgXwAJ4wfLfiihBpliOqmE6mPwMP0J/gUwCgtDnN
> dOd7zIJFfr2F0SJagu233q4=
> =xt9t
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Replicating properties in the context hierachy
Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Sorry for getting late in to this discussion. I have a very fundamental
question on this.
I assume that Axis2 clustering implementation is to have distributed
SOAP processing nodes.
If that is the case, Azeez why are you suggesting not to replicate all
the properties inside config context? We all agree that config context
holds system properties. If one node adds something to config context,
that should better be communicated/replicated to other nodes in the system.
What I feel is if you want to have a set of private properties then
those should not be inserted to config context. One option is to have a
context only for that node, but having different rules for naming the
properties to differentiate them seems not to be a clean idea, in a
distributed system.
The replication manager or whoever handles these communications should
not know about those rules. It should simply make sure all the nodes
have the same environment.
So IMHO, the best option is to have something like a NodeContext to have
those properties.
BTW, if I am off-topic, please discard this email ;)
Chinthaka
Afkham Azeez wrote:
> We have a problem when it comes to replicating properties in our
> clustering implementation. There are some properties which are specific
> to a node, specially properties in the ConfigurationContext. Some
> properties are added by different modules such as Sandesha2, Rampart to
> the ConfigurationContext. One thing is that these objects are not
> serializable, and the other thing is that these properties should not be
> replicated. Some information which are specific to a node may be added
> to the ConfigurationContexts, and these should never be replicated.
>
> So there should be some way to inform Axis2 about the properties that
> need to be clustered and those that shouldn't be clustered.
>
> I suggest we introduce a new Map to AbstractContext called
> clusterableProperties. Stuff that are added to this Map will be
> replicated, and the service author/module author has to add the
> properties that need to be replicated into the clusterableProperties Map.
>
> Thoughts?
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGURDCjON2uBzUhh8RAgXwAJ4wfLfiihBpliOqmE6mPwMP0J/gUwCgtDnN
dOd7zIJFfr2F0SJagu233q4=
=xt9t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org