[jboss-jira] [JBoss JIRA] Commented: (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment

[Stefano Maestri (JIRA)]

    [ https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631864#comment-12631864 ] 

Stefano Maestri commented on AS7-1994:
--------------------------------------

Brian said:

Some thoughts before I start PTO again (I'm in the Beijing office today.)

The exception happens because the OperationContextImpl enforces only updating the resource registry during stage MODEL. That's kind of arbitrary; I'll think about if it could be relaxed.

It could be hacked around by not subclassing AbstractAddStepHandler but just implementing it's logic directly and calling context.getResourceRegistrationForUpdate() in the MODEL stage handler. Then use it later. Of course if I'd accept a patch with such a hack I should just remove the check for stage MODEL.

The next question is the whole business of updating the resource registry from a service listener. The important thing is that operations acquire an exclusive lock on the ModelController. It's acquired when the first handler invokes any of the OperationContext methods that indicate the handler is going to mutate the model, the resource registry or the MSC services. (Read only ops don't acquired the lock.) It's released when that handler returns from execute(). Any mutation of the model/resource registry/MSC services must be done with that lock held. That semantic *must* be enforced; no patch that violates that will be accepted.

This service listener approach doesn't necessarily violate that semantic. During stage VERIFY the thread executing the operation will block until the MSC service container is settled and all demanded services have started or failed. That *could* mean this listener will have been invoked. What has to happen is some logic to make sure this listener can't be invoked some other time. E.g. if the service is restarted; if the service is ON-DEMAND and isn't demanded, etc. If any of those things happen the listener should not mutate the registry.

Hmm, that leads to the question of how this stuff gets cleaned up; e.g. what if the :reload operation is invoked? I think that should be ok, as the entire resource registry gets rebuilt.

But, what's definitely missing is ManagedResourceRegistration.removeSubModel()/removeMetric()/removeOperationHandler(). There's no way for a "remove" handler to delete this stuff! 

> access to the ModelNodeRegistration during handling of an operation and during deployment
> -----------------------------------------------------------------------------------------
>
>                 Key: AS7-1994
>                 URL: https://issues.jboss.org/browse/AS7-1994
>             Project: Application Server 7
>          Issue Type: Task
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Stefano Maestri
>            Assignee: Brian Stansberry
>             Fix For: 7.1.0.CR1
>
>
> Hi All,
> I'm trying to resume here the discussion I had yesterday on IRC with 
> Brian and Jesper.
> Basically JCA needs to have and already deployed instance of 
> ResourceAdapter when adding its metrics and some operation. The reason 
> for that is because some operation and metrics availability are known 
> only at runtime, depending from RA status and/or vendor specific feature 
> known only.
> Speaking from a Model point of view the basically issue is to have 
> access to the ModelNodeRegistration when the RA instance is created and 
> these runtime infos are available. There are 2 cases:
> 1) during handling ADD operation for a DataSource or special 
> ResourceAdapter creation withour rar deployment (like hornetQ).
> 2) during foo.rar deployment chain
> We have also discussed where we can put these operation in the model 
> tree. Also in this case there are two possible places:
> 1) at subsystem level for special no-deployment RA (DataSources and 
> HornetQ atm). So we will obtain something like  
> /subsystem=datasource/data-source=myDS and /subsystem=hq/ra
> 2) at DUP level /deployment=foo.rar Having this deployment support we 
> can remove the current operation in /subsystem=resource-adapters that is 
> redudant, referring the same RA (or better a subset of deployed ones)
> Hoping to have written all the matters discussed, feel free to integrate 
> and/or ask.
> regards
> S.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira