Please see my comments below.
On 8/25/06, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
The actual replication mechanism will depend on the ClusterManager implementation. The ClusterManager is just a abstraction which is used to make Axis2 free of the underneath clustering technology. The chellange is to come up with a proper interface which will leverage a certain implementation to do replication with minimum restrictions.
It is not needed for Contexts themselves to be serializable, nodes will simply be notifying each other in certain events like context creation and context destruction. Other nodes can simply create and destroy similar contexts within them. But when it comes to context properties this can be a proplem for certain clustering technologies. Chathura did a prototype ClusterManager implementation in JGroups. I guess he can explain more on this.
Yes this is a problem. In the first time the URLBasedAxisConfigurator can be used to get the data from the remote repository. But new resources added to the repository (for e.g. services) will not be reflected in the Nodes.
One mechanism may be to ask the users to maintain resource data in a file. For example users will have to update a services.lst file after adding a service to the repository. We should be able to ask the Hot Deployer to update itself based on theses lists.
Waiting for them :-)
Chamikara
Hi Guys,
This seems to be a very good proposal and +1 to go ahead. I am +1
*not* to cluster operation contexts and message contexts since the
overhead will be enormous and we would probably loose the advantage of
the clustering!
Anyway have you guys thought about the following issues ? (I'm not
sure whether these details are already discussed or not. If so bear
with me :))
1. How would the replication happen ?
How much resources would be used for clustering depends partly on
the mechanism we select to transfer the state - and of course this
brings up the issue whether the contexts are serializable or not
(Since our contexts are 'unrestricted' service authors can put all
sorts of junk there) ! As Rajith suggested we can use something like
JGroups or Tribes underneath or do we go for a relevant WS
specification ?
I believe there was an idea of using RSS for doing this!
The actual replication mechanism will depend on the ClusterManager implementation. The ClusterManager is just a abstraction which is used to make Axis2 free of the underneath clustering technology. The chellange is to come up with a proper interface which will leverage a certain implementation to do replication with minimum restrictions.
It is not needed for Contexts themselves to be serializable, nodes will simply be notifying each other in certain events like context creation and context destruction. Other nodes can simply create and destroy similar contexts within them. But when it comes to context properties this can be a proplem for certain clustering technologies. Chathura did a prototype ClusterManager implementation in JGroups. I guess he can explain more on this.
2. How can you deploy a service in the cluster ?
Since we are using a remote repository the ability to just drop in
an archive to the remote repo would not suffice (I suppose the lst
file needs to be modified too). This might be problematic if we have
a hot deployment mechanism.
Yes this is a problem. In the first time the URLBasedAxisConfigurator can be used to get the data from the remote repository. But new resources added to the repository (for e.g. services) will not be reflected in the Nodes.
One mechanism may be to ask the users to maintain resource data in a file. For example users will have to update a services.lst file after adding a service to the repository. We should be able to ask the Hot Deployer to update itself based on theses lists.
I'll come up with more comments when I get enough time to think
through the matters :)
Waiting for them :-)
