From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: "Paul Ferraro" <paul.ferraro(a)redhat.com&gt;, &quot;jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Thursday, September 13, 2012 8:27:25 PM Subject: HASingleton deployment Moving a discussion to the dev list. Paul, using parallel operations instead of storing metadata with the deployment resource itself has a couple drawbacks: 1) On restart of the server the special handling information implicit in the parallel deployment ops is lost and the deployment becomes a non-singleton.

2) In a managed domain, the "special" operation can propagate to the relevant servers in the domain at the time it is invoked, but subsequent to that if another server is added to a server group that runs this deployment, again the special handling information is lost.

The stuff Thomas is working on that I mentioned is at https://github.com/jbossas/jboss-as/pull/2790. On 9/12/12 12:17 AM, Paul Ferraro wrote: > I did spend some time thinking about while staring > out at the Mediterranean Sea this past week. > Fundamentally, implementing singleton deployments simply requires > wrapping the corresponding Service<DeploymentUnit> in a > SingletonService<DeploymentUnit>. The effect is the deployment > unit will be installed on all nodes in the cluster, but will start > on only 1 node at a time. The end result is more agile than what > we had in EAP5, since we're only starting/stopping existing > services, not creating them from from scratch. > From a domain model perspective, rather than tack on configuration > meta data to the deployment resource itself, I think it would be > simpler/cleaner to provide a parallel set of > deploy/undeploy/redeploy operations. The deploy/redeploy > operations will accept additional optional parameters for cluster > name and node preference (for a preferred node election policy). > For standalone mode, it might still be nice to provide a separate > file scanner using a distinct location that creates singleton > deployments. To clarify, this doesn't mean making the deployment > scanner itself a singleton service, but rather the operations > created by the scanner will install singleton deployment units > instead of normal deployment units. > > Thoughts/comments? > > Paul > > ----- Original Message ----- >> From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; >> To: "Paul Ferraro" <pferraro(a)redhat.com&gt; >> Sent: Wednesday, August 29, 2012 1:05:19 PM >> Subject: HASingleton related issues in the EAP 6.1 PRD >> >> Care to comment on $subject at >> https://docspace.corp.redhat.com/docs/DOC-105593 ? >> >> As I commented, I don't want to see an EAP 5-ish solution based on >> activating a scanner when a node becomes master. That would be a >> standalone-only hack. I think something along the lines of >> associating >> some configuration metadata with the deployment=* resource in the >> management model makes more sense, and then some clustering >> integration >> to "(de)activate" the deployment. >> >> If you agree, we should chat about this a bit on the jboss-as7-dev >> list >> before you go. The "associating some configuration metadata with >> the >> deployment=* resource" part intersects with some stuff Thomas >> Diesler >> was trying to do, and the "activate the deployment" part >> intersects >> with >> some stuff Stuart Douglas was working on, as well as some OSGi >> stuff. >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

Paul Ferraro wrote: > ----- Original Message ----- >> From: "Brian Stansberry&quot;&lt;brian.stansberry(a)redhat.com&gt; >> To: "Paul Ferraro&quot;&lt;paul.ferraro(a)redhat.com&gt;, >> &quot;jboss-as7-dev(a)lists.jboss.org Development" >> <jboss-as7-dev(a)lists.jboss.org&gt; >> Sent: Thursday, September 13, 2012 8:27:25 PM >> Subject: HASingleton deployment >> >> Moving a discussion to the dev list. >> >> Paul, using parallel operations instead of storing metadata with the >> deployment resource itself has a couple drawbacks: >> >> 1) On restart of the server the special handling information implicit >> in >> the parallel deployment ops is lost and the deployment becomes a >> non-singleton. > > I didn't mean to imply that these operations would create plain > deployment=* resources - rather these separate operations would create > separate resources representing singleton deployments. e.g. > singleton-deployment=* > > This keeps the two types of deployments, I think, appropriately > segregated. This would prevent, say, someone starting a deployment (a > typical operation) on a node even though some other node is designated > master. Also, the management console would want a separate section to > display singleton-deployments, indicating the status of a given > deployment on each server. > I don't think this really does help in that case. Either way the person doing the deployment has to know to do a ha singleton deployment, rather than a normal deployment.

Stuart >> 2) In a managed domain, the "special" operation can propagate to the >> relevant servers in the domain at the time it is invoked, but >> subsequent >> to that if another server is added to a server group that runs this >> deployment, again the special handling information is lost. > > Again, the processing of an singleton-deployment resource would take > care of this. > >> The stuff Thomas is working on that I mentioned is at >> https://github.com/jbossas/jboss-as/pull/2790. >> >> On 9/12/12 12:17 AM, Paul Ferraro wrote: >>> I did spend some time thinking about while staring >>> out at the Mediterranean Sea this past week. >>> Fundamentally, implementing singleton deployments simply requires >>> wrapping the corresponding Service<DeploymentUnit> in a >>> SingletonService<DeploymentUnit>. The effect is the deployment >>> unit will be installed on all nodes in the cluster, but will start >>> on only 1 node at a time. The end result is more agile than what >>> we had in EAP5, since we're only starting/stopping existing >>> services, not creating them from from scratch. >>> From a domain model perspective, rather than tack on configuration >>> meta data to the deployment resource itself, I think it would be >>> simpler/cleaner to provide a parallel set of >>> deploy/undeploy/redeploy operations. The deploy/redeploy >>> operations will accept additional optional parameters for cluster >>> name and node preference (for a preferred node election policy). >>> For standalone mode, it might still be nice to provide a separate >>> file scanner using a distinct location that creates singleton >>> deployments. To clarify, this doesn't mean making the deployment >>> scanner itself a singleton service, but rather the operations >>> created by the scanner will install singleton deployment units >>> instead of normal deployment units. >>> >>> Thoughts/comments? >>> >>> Paul >>> >>> ----- Original Message ----- >>>> From: "Brian Stansberry&quot;&lt;brian.stansberry(a)redhat.com&gt; >>>> To: "Paul Ferraro&quot;&lt;pferraro(a)redhat.com&gt; >>>> Sent: Wednesday, August 29, 2012 1:05:19 PM >>>> Subject: HASingleton related issues in the EAP 6.1 PRD >>>> >>>> Care to comment on $subject at >>>> https://docspace.corp.redhat.com/docs/DOC-105593 ? >>>> >>>> As I commented, I don't want to see an EAP 5-ish solution based on >>>> activating a scanner when a node becomes master. That would be a >>>> standalone-only hack. I think something along the lines of >>>> associating >>>> some configuration metadata with the deployment=* resource in the >>>> management model makes more sense, and then some clustering >>>> integration >>>> to "(de)activate" the deployment. >>>> >>>> If you agree, we should chat about this a bit on the jboss-as7-dev >>>> list >>>> before you go. The "associating some configuration metadata with >>>> the >>>> deployment=* resource" part intersects with some stuff Thomas >>>> Diesler >>>> was trying to do, and the "activate the deployment" part >>>> intersects >>>> with >>>> some stuff Stuart Douglas was working on, as well as some OSGi >>>> stuff. >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Software Engineer >>>> JBoss by Red Hat >>>> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev