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