[jboss-as7-dev] HASingleton deployment

[Brian Stansberry]

On 9/14/12 8:46 PM, Stuart Douglas wrote:
>
>
> Paul Ferraro wrote:
>> ----- Original Message -----
>>> From: "Brian Stansberry"<brian.stansberry at redhat.com>
>>> To: "Paul Ferraro"<paul.ferraro at redhat.com>,
>>> "jboss-as7-dev at lists.jboss.org Development"
>>> <jboss-as7-dev at lists.jboss.org>
>>> 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.
>

The concern I have with a new top-level type for these is it becomes 
part of the core API, but depends on subsystem functionality to actually 
work. That's a conceptual mismatch.

That's an inherent problem with this kind of thing; same applies to the 
OSGi stuff I linked. If the subsystem-specific config is a child of 
<deployment> and is namespaced similarly to how <profile> and 
<subsystem> works it's a bit cleaner. Still not really clean though.

> 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"<brian.stansberry at redhat.com>
>>>>> To: "Paul Ferraro"<pferraro at redhat.com>
>>>>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat