<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yeah feels like we are <a href="http://apache.org">apache.org</a> </div><div><br></div><div>+1<br><br><br><div><br></div></div><div><br>Am 02.07.2015 um 11:33 schrieb Tomaž Cerar <<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr">So if we are doing +1s, then <br>+1 <br><br>:)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan <span dir="ltr"><<a href="mailto:kabir.khan@jboss.com" target="_blank">kabir.khan@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Me too<br>
<div class="HOEnZb"><div class="h5">> On 1 Jul 2015, at 20:03, Jason Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>> wrote:<br>
><br>
> I completely agree.<br>
><br>
>> On Jul 1, 2015, at 11:43 AM, Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br>
>><br>
>> tl;dr;<br>
>><br>
>> When an operation that has changed the management model is rolling back,<br>
>> the OperationStepHandlers processing the rollback see the model as it<br>
>> was at the arbitrary point when the rollback began. I propose changing<br>
>> this so they see things as they were prior to the first change to the model.<br>
>><br>
>> Long version:<br>
>><br>
>> When an operation mutates either the management Resource tree, or the<br>
>> registry of capabilities (together known as the management model), we<br>
>> clone the management model and thereafter that operation works on the<br>
>> clone. The clone is invisible to other callers until the operations<br>
>> successfully commits. When the operation commits, it publishes the clone<br>
>> and that becomes the official model.<br>
>><br>
>> I call this copy-on-write, publish-on-commit.<br>
>><br>
>> If the operation rolls back, the changed model is never published and<br>
>> the clone is just discarded when the operation execution returns.<br>
>><br>
>> However, while the operation is rolling back, all the<br>
>> OperationStepHandlers that are processing the rollback see the modified<br>
>> clone, not the original model. They are seeing arbitrarily incorrect data.<br>
>><br>
>> This hasn't been a problem up to now, as our standard OSHs get a copy of<br>
>> whatever part of the Resource tree they are going to modify and keep it<br>
>> for use in rollback. They don't need to re-read the management model to<br>
>> perform rollback.<br>
>><br>
>> But this doesn't work for the capability registry. If an OSH removes a<br>
>> capability and removes a service, and then in rollback tries to use the<br>
>> capability to figure out how to restore the service, it fails, as<br>
>> management model it can see still shows the capability as being removed.<br>
>><br>
>> To fix this, I propose discarding the cloned management model as soon as<br>
>> rollback begins. Thereafter, an OSH processing rollback will see the<br>
>> model as it was before the first modification. The removed capability<br>
>> will still be present.<br>
>><br>
>> I have a commit that does this at [1]. Running the testsuite with it<br>
>> shows no regressions. This doesn't surprise me, as our standard OSHs up<br>
>> to now have had no need to re-read the model during rollback.<br>
>><br>
>> [1]<br>
>> <a href="https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be" rel="noreferrer" target="_blank">https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be</a><br>
>><br>
>> --<br>
>> Brian Stansberry<br>
>> Senior Principal Software Engineer<br>
>> JBoss by Red Hat<br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
> --<br>
> Jason T. Greene<br>
> WildFly Lead / JBoss EAP Platform Architect<br>
> JBoss, a division of Red Hat<br>
><br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>wildfly-dev mailing list</span><br><span><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></div></blockquote></body></html>