My comments are inline, marked with [RA]
Regards,
Rajith
On 8/25/06, Ajith Ranabahu <
[EMAIL PROTECTED]> wrote:
[RA] Contexts need not be serializable !!! , we are not going to move the context across the wire.
We are only going to move the properties across, so the properties have to be serializable.
The service authors cannot put any junk they want. What ever they put
a) has to be serializable. (for example the servlet spec mandates this for HttpSession)
b) should be small and simple objects
If they put large complex objects in the session then they will pay a hell of a price if clustering is enabled.
Most people are experianced with web programming and are aware of the limitations/best practices around web sessions.
So it's not going to be a problem. However we need to clearly add these things in the documentation.
[RA] The best way to do hot deployment is to have "farming". But this is complicated and difficult to implement.
So thats why I suggested to leave it for phase two.
Other option is to hot deploy manually in every node (which maybe ok if the number of nodes is like 5 or 6)
But if this is a really pressing concern then we can attempt to do farming in the current phase.
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!
[RA] Contexts need not be serializable !!! , we are not going to move the context across the wire.
We are only going to move the properties across, so the properties have to be serializable.
The service authors cannot put any junk they want. What ever they put
a) has to be serializable. (for example the servlet spec mandates this for HttpSession)
b) should be small and simple objects
If they put large complex objects in the session then they will pay a hell of a price if clustering is enabled.
Most people are experianced with web programming and are aware of the limitations/best practices around web sessions.
So it's not going to be a problem. However we need to clearly add these things in the documentation.
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.
[RA] The best way to do hot deployment is to have "farming". But this is complicated and difficult to implement.
So thats why I suggested to leave it for phase two.
Other option is to hot deploy manually in every node (which maybe ok if the number of nodes is like 5 or 6)
But if this is a really pressing concern then we can attempt to do farming in the current phase.
I'll come up with more comments when I get enough time to think
through the matters :)
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
