Discarding the changed management model during operation rollback

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Discarding the changed management model during operation rollback

Brian Stansberry
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/419f350931d5b7e345cf9aa514de08c01bf976be

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Discarding the changed management model during operation rollback

James Perkins
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/419f350931d5b7e345cf9aa514de08c01bf976be
>

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Discarding the changed management model during operation rollback

jtgreene
Administrator
In reply to this post by Brian Stansberry
I completely agree.

> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <[hidden email]> 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/419f350931d5b7e345cf9aa514de08c01bf976be
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Discarding the changed management model during operation rollback

kkhan
Me too

> On 1 Jul 2015, at 20:03, Jason Greene <[hidden email]> wrote:
>
> I completely agree.
>
>> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <[hidden email]> 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/419f350931d5b7e345cf9aa514de08c01bf976be
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Discarding the changed management model during operation rollback

Tomaž Cerar-2
So if we are doing +1s, then
+1

:)

On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <[hidden email]> wrote:
Me too
> On 1 Jul 2015, at 20:03, Jason Greene <[hidden email]> wrote:
>
> I completely agree.
>
>> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <[hidden email]> 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/419f350931d5b7e345cf9aa514de08c01bf976be
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Discarding the changed management model during operation rollback

Heiko Braun
Yeah feels like we are apache.org 

+1




Am 02.07.2015 um 11:33 schrieb Tomaž Cerar <[hidden email]>:

So if we are doing +1s, then
+1

:)

On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <[hidden email]> wrote:
Me too
> On 1 Jul 2015, at 20:03, Jason Greene <[hidden email]> wrote:
>
> I completely agree.
>
>> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <[hidden email]> 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/419f350931d5b7e345cf9aa514de08c01bf976be
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev