Re: [jboss-as7-dev] HASingleton deployment

----- 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.

> 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