11:43 a.m.
tl;dr;
When an operation that has changed the management model is rolling back,
the OperationStepHandlers processing the rollback see the model as it
was at the arbitrary point when the rollback began. I propose changing
this so they see things as they were prior to the first change to the model.
Long version:
When an operation mutates either the management Resource tree, or the
registry of capabilities (together known as the management model), we
clone the management model and thereafter that operation works on the
clone. The clone is invisible to other callers until the operations
successfully commits. When the operation commits, it publishes the clone
and that becomes the official model.
I call this copy-on-write, publish-on-commit.
If the operation rolls back, the changed model is never published and
the clone is just discarded when the operation execution returns.
However, while the operation is rolling back, all the
OperationStepHandlers that are processing the rollback see the modified
clone, not the original model. They are seeing arbitrarily incorrect data.
This hasn't been a problem up to now, as our standard OSHs get a copy of
whatever part of the Resource tree they are going to modify and keep it
for use in rollback. They don't need to re-read the management model to
perform rollback.
But this doesn't work for the capability registry. If an OSH removes a
capability and removes a service, and then in rollback tries to use the
capability to figure out how to restore the service, it fails, as
management model it can see still shows the capability as being removed.
To fix this, I propose discarding the cloned management model as soon as
rollback begins. Thereafter, an OSH processing rollback will see the
model as it was before the first modification. The removed capability
will still be present.
I have a commit that does this at [1]. Running the testsuite with it
shows no regressions. This doesn't surprise me, as our standard OSHs up
to now have had no need to re-read the model during rollback.
[1]
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:01 p.m.
Not much more I can say than +1.
I can't think of a good reason why an OSH would need to know anything
about the failed model update on a rollback.
On 07/01/2015 09:43 AM, Brian Stansberry wrote:
tl;dr;
When an operation that has changed the management model is rolling back,
the OperationStepHandlers processing the rollback see the model as it
was at the arbitrary point when the rollback began. I propose changing
this so they see things as they were prior to the first change to the model.
Long version:
When an operation mutates either the management Resource tree, or the
registry of capabilities (together known as the management model), we
clone the management model and thereafter that operation works on the
clone. The clone is invisible to other callers until the operations
successfully commits. When the operation commits, it publishes the clone
and that becomes the official model.
I call this copy-on-write, publish-on-commit.
If the operation rolls back, the changed model is never published and
the clone is just discarded when the operation execution returns.
However, while the operation is rolling back, all the
OperationStepHandlers that are processing the rollback see the modified
clone, not the original model. They are seeing arbitrarily incorrect data.
This hasn't been a problem up to now, as our standard OSHs get a copy of
whatever part of the Resource tree they are going to modify and keep it
for use in rollback. They don't need to re-read the management model to
perform rollback.
But this doesn't work for the capability registry. If an OSH removes a
capability and removes a service, and then in rollback tries to use the
capability to figure out how to restore the service, it fails, as
management model it can see still shows the capability as being removed.
To fix this, I propose discarding the cloned management model as soon as
rollback begins. Thereafter, an OSH processing rollback will see the
model as it was before the first modification. The removed capability
will still be present.
I have a commit that does this at [1]. Running the testsuite with it
shows no regressions. This doesn't surprise me, as our standard OSHs up
to now have had no need to re-read the model during rollback.
[1]
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
--
James R. Perkins
JBoss by Red Hat
1:03 p.m.
I completely agree.
On Jul 1, 2015, at 11:43 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
tl;dr;
When an operation that has changed the management model is rolling back,
the OperationStepHandlers processing the rollback see the model as it
was at the arbitrary point when the rollback began. I propose changing
this so they see things as they were prior to the first change to the model.
Long version:
When an operation mutates either the management Resource tree, or the
registry of capabilities (together known as the management model), we
clone the management model and thereafter that operation works on the
clone. The clone is invisible to other callers until the operations
successfully commits. When the operation commits, it publishes the clone
and that becomes the official model.
I call this copy-on-write, publish-on-commit.
If the operation rolls back, the changed model is never published and
the clone is just discarded when the operation execution returns.
However, while the operation is rolling back, all the
OperationStepHandlers that are processing the rollback see the modified
clone, not the original model. They are seeing arbitrarily incorrect data.
This hasn't been a problem up to now, as our standard OSHs get a copy of
whatever part of the Resource tree they are going to modify and keep it
for use in rollback. They don't need to re-read the management model to
perform rollback.
But this doesn't work for the capability registry. If an OSH removes a
capability and removes a service, and then in rollback tries to use the
capability to figure out how to restore the service, it fails, as
management model it can see still shows the capability as being removed.
To fix this, I propose discarding the cloned management model as soon as
rollback begins. Thereafter, an OSH processing rollback will see the
model as it was before the first modification. The removed capability
will still be present.
I have a commit that does this at [1]. Running the testsuite with it
shows no regressions. This doesn't surprise me, as our standard OSHs up
to now have had no need to re-read the model during rollback.
[1]
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
2:49 a.m.
Me too
On 1 Jul 2015, at 20:03, Jason Greene <jason.greene(a)redhat.com>
wrote:
I completely agree.
> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> tl;dr;
>
> When an operation that has changed the management model is rolling back,
> the OperationStepHandlers processing the rollback see the model as it
> was at the arbitrary point when the rollback began. I propose changing
> this so they see things as they were prior to the first change to the model.
>
> Long version:
>
> When an operation mutates either the management Resource tree, or the
> registry of capabilities (together known as the management model), we
> clone the management model and thereafter that operation works on the
> clone. The clone is invisible to other callers until the operations
> successfully commits. When the operation commits, it publishes the clone
> and that becomes the official model.
>
> I call this copy-on-write, publish-on-commit.
>
> If the operation rolls back, the changed model is never published and
> the clone is just discarded when the operation execution returns.
>
> However, while the operation is rolling back, all the
> OperationStepHandlers that are processing the rollback see the modified
> clone, not the original model. They are seeing arbitrarily incorrect data.
>
> This hasn't been a problem up to now, as our standard OSHs get a copy of
> whatever part of the Resource tree they are going to modify and keep it
> for use in rollback. They don't need to re-read the management model to
> perform rollback.
>
> But this doesn't work for the capability registry. If an OSH removes a
> capability and removes a service, and then in rollback tries to use the
> capability to figure out how to restore the service, it fails, as
> management model it can see still shows the capability as being removed.
>
> To fix this, I propose discarding the cloned management model as soon as
> rollback begins. Thereafter, an OSH processing rollback will see the
> model as it was before the first modification. The removed capability
> will still be present.
>
> I have a commit that does this at [1]. Running the testsuite with it
> shows no regressions. This doesn't surprise me, as our standard OSHs up
> to now have had no need to re-read the model during rollback.
>
> [1]
>
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:33 a.m.
So if we are doing +1s, then
+1
:)
On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <kabir.khan(a)jboss.com> wrote:
Me too
> On 1 Jul 2015, at 20:03, Jason Greene <jason.greene(a)redhat.com> wrote:
>
> I completely agree.
>
>> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
>>
>> tl;dr;
>>
>> When an operation that has changed the management model is rolling back,
>> the OperationStepHandlers processing the rollback see the model as it
>> was at the arbitrary point when the rollback began. I propose changing
>> this so they see things as they were prior to the first change to the
model.
>>
>> Long version:
>>
>> When an operation mutates either the management Resource tree, or the
>> registry of capabilities (together known as the management model), we
>> clone the management model and thereafter that operation works on the
>> clone. The clone is invisible to other callers until the operations
>> successfully commits. When the operation commits, it publishes the clone
>> and that becomes the official model.
>>
>> I call this copy-on-write, publish-on-commit.
>>
>> If the operation rolls back, the changed model is never published and
>> the clone is just discarded when the operation execution returns.
>>
>> However, while the operation is rolling back, all the
>> OperationStepHandlers that are processing the rollback see the modified
>> clone, not the original model. They are seeing arbitrarily incorrect
data.
>>
>> This hasn't been a problem up to now, as our standard OSHs get a copy of
>> whatever part of the Resource tree they are going to modify and keep it
>> for use in rollback. They don't need to re-read the management model to
>> perform rollback.
>>
>> But this doesn't work for the capability registry. If an OSH removes a
>> capability and removes a service, and then in rollback tries to use the
>> capability to figure out how to restore the service, it fails, as
>> management model it can see still shows the capability as being removed.
>>
>> To fix this, I propose discarding the cloned management model as soon as
>> rollback begins. Thereafter, an OSH processing rollback will see the
>> model as it was before the first modification. The removed capability
>> will still be present.
>>
>> I have a commit that does this at [1]. Running the testsuite with it
>> shows no regressions. This doesn't surprise me, as our standard OSHs up
>> to now have had no need to re-read the model during rollback.
>>
>> [1]
>>
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:12 a.m.
Yeah feels like we are apache.org
+1
Am 02.07.2015 um 11:33 schrieb Tomaž Cerar
<tomaz.cerar(a)gmail.com>:
So if we are doing +1s, then
+1
:)
> On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <kabir.khan(a)jboss.com> wrote:
> Me too
> > On 1 Jul 2015, at 20:03, Jason Greene <jason.greene(a)redhat.com> wrote:
> >
> > I completely agree.
> >
> >> On Jul 1, 2015, at 11:43 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> >>
> >> tl;dr;
> >>
> >> When an operation that has changed the management model is rolling back,
> >> the OperationStepHandlers processing the rollback see the model as it
> >> was at the arbitrary point when the rollback began. I propose changing
> >> this so they see things as they were prior to the first change to the
model.
> >>
> >> Long version:
> >>
> >> When an operation mutates either the management Resource tree, or the
> >> registry of capabilities (together known as the management model), we
> >> clone the management model and thereafter that operation works on the
> >> clone. The clone is invisible to other callers until the operations
> >> successfully commits. When the operation commits, it publishes the clone
> >> and that becomes the official model.
> >>
> >> I call this copy-on-write, publish-on-commit.
> >>
> >> If the operation rolls back, the changed model is never published and
> >> the clone is just discarded when the operation execution returns.
> >>
> >> However, while the operation is rolling back, all the
> >> OperationStepHandlers that are processing the rollback see the modified
> >> clone, not the original model. They are seeing arbitrarily incorrect data.
> >>
> >> This hasn't been a problem up to now, as our standard OSHs get a copy
of
> >> whatever part of the Resource tree they are going to modify and keep it
> >> for use in rollback. They don't need to re-read the management model to
> >> perform rollback.
> >>
> >> But this doesn't work for the capability registry. If an OSH removes a
> >> capability and removes a service, and then in rollback tries to use the
> >> capability to figure out how to restore the service, it fails, as
> >> management model it can see still shows the capability as being removed.
> >>
> >> To fix this, I propose discarding the cloned management model as soon as
> >> rollback begins. Thereafter, an OSH processing rollback will see the
> >> model as it was before the first modification. The removed capability
> >> will still be present.
> >>
> >> I have a commit that does this at [1]. Running the testsuite with it
> >> shows no regressions. This doesn't surprise me, as our standard OSHs up
> >> to now have had no need to re-read the model during rollback.
> >>
> >> [1]
> >>
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
> >>
> >> --
> >> Brian Stansberry
> >> Senior Principal Software Engineer
> >> JBoss by Red Hat
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3430
days inactive
3431
days old
5 comments
6 participants
participants (6)
-
Brian Stansberry -
Heiko Braun -
James R. Perkins -
Jason Greene -
Kabir Khan -
Tomaž Cerar