Re: [jboss-as7-dev] HASingleton deployment

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