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* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
