[Design of POJO Server] - Re: profile service, farming
by bstansberry＠jboss.com
Bit of a brain dump here. Any comments on my wrongheadedness would be much appreciated. :)
When I think about what the clustering services inside the AS will be doing with clustered deployments, I see two main things:
1) Keeping repositories in sync if people are using individual local filesystem repos on each node. This task is minor/optional/secondary, but I include it for completeness.
2) Coordinating deployments around the cluster as the ProfileService running on each node becomes aware of changes in the repository. Ensure each node is aware of the change, use a configurable policy to execute the deployment (e.g. sequentially or simultaneously), extend any 2PC deployment capability the profile service exposes to a cluster-wide operation. This is the more significant task.
Keeping repositories in sync
------------------------------------
Again, this is IMHO the less meaningful task, but one that seems pretty straighforward. Only relevant if the repository is the local filesystem, not enabled by default (even in an 'all' config).
1.As with deployers/ and deploy/ there is a scanner that reads a set of URIs (e.g. farm/) and presents deployments to the ProfileService
2.On startup before presenting deployments to ProfileService it reconciles the state of farm/ with the cluster, brings over added deployments not available locally, brings over modified deployments, removes deployments previously removed from cluster but still present locally.
3.After startup, no longer presents things to the ProfileService; the profile service is responsible for scanning for changes itself.
4.After startup, however, it continues to scan the farm/ dir for purposes of noticing changes and replicating them around the cluster.
Coordinating deployments
----------------------------------
Here things get more fuzzy. "Coordinating" basically means either a) controlling the initiating of the deployment process on each node, or b) somehow pausing it in the middle and exchanging messages around the cluster until the cluster-wide state is appropriate and then resuming, or c) some combination of both.
To me using a) implies some variant of the HDScanner concept -- i.e something that periodically queries the Profile for modified deployments and then invokes on MainDeployer to undeploy the old version and deploy the new version. Looking at the MainDeployer API it looks like it exposes enough methods for pretty fine grained control of this; e.g. the change(String, DeploymentStage) method implies the ability to walk things through deploy/undeploy step by step.
Using b) implies writing a specialized Deployer(s) that does coordination in the deploy()/undeploy() methods. That seems conceptually wrong to me; i.e. a bit outside of the scope of what a deployer should be doing.
An advantage of doing it in a Deployer is the possibility of using metadata that an earlier deployer could make available. For example, a bean annotated with @Farm or a war with a special tag in jboss-web.xml could be cluster-deployed without needing to be associated with DeploymentPhase.APPLICATION_CLUSTERED.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152451#4152451
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152451
18 years
[Design the new POJO MicroContainer] - Re: expressing dependent states
by adrian＠jboss.org
"jhalliday" wrote :
| Is that right? Does MC actually use or plan to use concurrent startup to speed things up? If so, there is potential advantage in sticking with parameter injection rather than injecting it as a property on my bean.
Yes, but I don't really see how delaying the injection increases the concurrency?
In most circumstances if you have dependencies they are going to wait until
you are fully installed so it doesn't really matter if you inject some other service
into a property or a lifecycle method.
On an aesthetic point, some advocates of IOC (e.g. nano/pico container) suggest
you should inject into the constructor parameters since then you can
be immutable and it is less error prone (you are forced to inject all the parameters
while people are not forced to set all the properties or configure lifecycle methods).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152439#4152439
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152439
18 years
[Design the new POJO MicroContainer] - Re: expressing dependent states
by jhalliday
wow, cool.
So in that case injecting it as a property of my bean will give the same value as injecting it as a parameter of a lifecycle method call. The difference I guess is limited to the potential for concurrent execution.
In the case of injection as a bean property, the lifecycles must be strictly serial ordered. Whereas, with lifecycle method parameter injection, the bean on which the injection is occurring can go through any of the lifecycle phases before the one for which it requires the injected parameter, concurrently with the lifecycle of the bean that will be injected.
Is that right? Does MC actually use or plan to use concurrent startup to speed things up? If so, there is potential advantage in sticking with parameter injection rather than injecting it as a property on my bean.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152425#4152425
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152425
18 years