[midPoint] HA: HA: HA: Prohibit having particular assignments
Pavol Mederly
mederly at evolveum.com
Tue May 26 17:42:44 CEST 2015
Well, the main problem is in the addSecondaryDelta method. It is a
method in LensElementContext, a superclass of LensFocusContext and
LensProjectionContext. And the focus just ignores secondaryDelta; it
uses secondaryDeltas instead. I understand that this is (at best)
misleading - and I'll fix this (MID-2381
<https://jira.evolveum.com/browse/MID-2381>).
In the meanwhile, I have two options for you; preferring the second one.
The first one is to use correct method to set the secondary delta -
along with correctly computing the delta itself.
focusClone = focus.clone();
focusClone.assignment.removeAll(rolesToDelete);
delta = focus.asPrismObject().diff(focusClone.asPrismObject());
log.info("delta = {}", delta.debugDump());
for (itemDelta in delta.getModifications()) {
modelContext.focusContext.swallowToSecondaryDelta(itemDelta);
}
As you can see, I've left out the getObject operation. Because in your
case, you were comparing the computed ObjectNew state with original
object state in repository. They may differ in much more than the
assignments you want to delete. In contrast to that, what I suggest
concentrates only on the role assignment removal. And, it does not
modify objects in the model context; it modifies a clone instead.
But there still is the question of (possible) secondary delta
recomputation yielding the loss of your added delta. So I would not
hesitate to put the changes directly into the primary delta, to be sure
they will not be lost during the processing:
focusClone = focus.clone();
focusClone.assignment.removeAll(rolesToDelete);
delta = focus.asPrismObject().diff(focusClone.asPrismObject());
log.info("delta = {}", delta.debugDump());
modelContext.focusContext.addPrimaryDelta(delta);
modelContext.setFresh(false);
SetFresh(false) causes immediate recomputation of the context.
I've tested both options in my environment and they seem to work (tested
with removing all assignment, not only selected ones).
Hope this helps,
Pavol
On 26. 5. 2015 16:52, Pavol Mederly wrote:
> Hello Алексей,
>
> I've studied the logs you've sent here.
>
> Look at the line 9182, just after the text "2015-05-26 12:46:50,285
> TRACE: Evaluating hook 'Example scripting hook'".
>
> You see that "User old" and "User current" have all the assignments,
> namely:
>
> assignment:
> id=2
> targetRef:
> oid=5e8b8660-a788-4b7c-8a6c-f08f3ff3d4a1(RoleType)
> id=3
> targetRef:
> oid=7faa8e52-d8d8-487f-8a25-987a0eaf4521(RoleType)
> id=4
> targetRef:
> oid=cdb06bb4-c134-4ce5-b0f9-483b32832114(RoleType)
> id=5
> targetRef:
> oid=3427d715-52a1-4806-9f81-0304f57ffb90(RoleType)
> id=1
> targetRef:
> oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
>
> and "User new" does not have them. So far so good.
>
> BUT.
>
> The secondary delta(s) do not contain the delta that caused that removal:
>
> User secondary delta:
> ObjectDeltaWaves:2 waves
> wave 0:
> ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
> extension/hrStatus
> REPLACE: REJ
> assignment
> ADD:
> id=null
> targetRef:
> oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
> DELETE:
> id=null
> targetRef:
> oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
> activation/administrativeStatus
> REPLACE: DISABLED
> parentOrgRef
> ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
> DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
> wave 1:
> ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
> extension/hrStatus
> REPLACE: REJ
> activation/effectiveStatus
> REPLACE: DISABLED
> activation/disableTimestamp
> REPLACE: 2015-05-26T12:46:45.745+03:00
> parentOrgRef
> ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
> DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
>
> And the deltas are what counts. ChangeExecutor executes deltas, not
> the "User new" state. The "User new" state is dynamically recomputed
> (using deltas), at many places.
>
> I'm refering to this code:
>
> result = new OperationResult("get_object_by_oid");
> task = taskManager.createTaskInstance("get_user_by_oid");
> focus.assignment.removeAll(rolesToDelete);
> current = modelController.getObject(UserType.class, focus.oid, null,
> task, result);
> delta = current.diff(focus.asPrismObject(), true, true);
> context.engineScope.get("modelContext").focusContext.addSecondaryDelta(delta)
>
> So, I have two recommendation:
> 1) Do not call removeAll(rolesToDelete) on live object from the model
> context. Use a clone instead.
> 2) Try to find why the computed deltas are not incorporated in the
> context.
>
> As for 2, I would recommend putting some kind of logging to make sure
> the delta is computed well.
> In particular, I would replace current.diff(focus.asPrismObject(),
> true, true) by
> current.diff(focus.asPrismObject()).But that does not seem like the cause.
>
> There's probably one more caveat - not showing in your particular
> case, but still present.
> If you put something into secondary delta, there's a risk that these
> deltas will get recomputed
> if clockwork would think that the context is not fresh - around lines
> 236-241 of Clockwork:
> if(!context.isFresh()) {
> context.cleanup();
> projector.project(context,"PROJECTOR ("+state+")", task, result);
> }else{
> LOGGER.trace("Skipping projection because the context is fresh");
> }
> Note that the projector.project simply re-computes secondary deltas
> from the beginning (i.e. from the primary delta). I'm not sure how to
> work around this. (Rado? Have you any idea?) Maybe modifying the
> primary delta instead of secondary one? Or just hoping this situation
> would not occur? :)
>
> Anyway, if I find a little bit more time, I could play for a while
> with this. Until that, you could consider modifying your code
> according to the recommendations above.
>
> Regards,
> Pavol
>
> On 26. 5. 2015 11:59, Алексей Ващенков wrote:
>> Send the log in attachment
>> ________________________________________
>> От: midPoint [midpoint-bounces at lists.evolveum.com] от имени Pavol Mederly [pavol.mederly at gmail.com]
>> Отправлено: 26 мая 2015 г. 12:38
>> Кому:midpoint at lists.evolveum.com
>> Тема: Re: [midPoint] HA: HA: Prohibit having particular assignments
>>
>> I think this threadhttps://lists.evolveum.com/pipermail/midpoint/2015-May/000995.html would be a better place to discuss this issue because the initial problem is rooted there.
>>
>> OK, so continuing here.
>>
>>
>> System configuration is in attachments. How properly setup logs? If I enable model logger to debug, then each time hook is fired logs increase by 6MB
>>
>> Yes, model diagnostic is quite verbose. Anyway, I suggest the following:
>>
>> <classLogger>
>> <level>TRACE</level>
>> <package>com.evolveum.midpoint.model.impl.lens.Clockwork</package>
>> </classLogger>
>> <classLogger>
>> <level>TRACE</level>
>> <package>com.evolveum.midpoint.model.impl.lens.projector.Projector</package>
>> </classLogger>
>>
>> ...and remove the DEBUG placed at the level of model, i.e. this one:
>>
>> <classLogger>
>> <level>DEBUG</level>
>> <package>com.evolveum.midpoint.model</package>
>> <appender>IDM-PROFILE_LOG</appender>
>> </classLogger>
>>
>> I really suspect that the secondary deltas get recomputed during the process.
>>
>> Pavol
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150526/775f00e0/attachment.htm>
More information about the midPoint
mailing list