[midPoint] Upgrade from 3.6 to 3.7 (standalone) leaves ownerref empty on tasks, can't start midPoint

[Pavol Mederly]

Hello Ramón,

As for the iOpExecOwnerOid being already present, I do apologize. When 
finalizing SQL update scripts I have checked against "3.6-all" scripts, 
and the index is not there. It somehow got into upgrade scripts without 
modifying the "full" ones.

---

As for the missing ownerRef, it should not prevent midPoint from starting.

It should only cause the initial task synchronization procedure to 
report some problems,  but midPoint as such should continue to load (and 
eventually start successfully). I have now tested it on code almost 
identical to 3.7, both in "tomcat" and standalone mode. The issue 
manifests itself as the exception you mentioned, plus a summarizing message:

/2018-01-22 13:28:42,632 [] [RMI TCP Connection(3)-127.0.0.1] INFO 
(com.evolveum.midpoint.task.quartzimpl.execution.TaskSynchronizer): 
Synchronization of midpoint and Quartz task store finished. 4 task(s) 
existing in midPoint repository successfully processed, resulting in 2 
updated Quartz job(s). 0 task(s) removed from Quartz job store. 
//*Processing of 1 task(s) failed*//./

(More tasks, in your case.) And the midPoint starts well.

---

As far as I know, the issue is not related to version change from 3.6 to 
3.7. The code that checks ownerRef is there since 2012. And the tasks 
themselves contain the ownerRef also since they were created (in 
04/2015). It looks like the data got wrong (somehow) in your 
installation only. But, nevertheless, it should not be a cause of 
midPoint not starting.

How does your log file continue? Could you post here more of it?

The easiest way to repair the state is to start midPoint somehow, and 
then to add ownerRef directly into XML representation of the particular 
tasks; via Repository Objects, like this:

It is because this XML (stored in fullObject db column) is used as the 
authoritative information on each midPoint object. All other db columns 
are derived from it; in fact, they are present only to facilitate 
searching for objects according to specified criteria.

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 22.01.2018 12:19, Ramón Cahenzli wrote:
> Hello everyone,
>
> We run midPoint on Debian with PostgreSQL. I've upgraded one of our dev
> instances successfully to 3.7 with no issues, apart for the problem
> that the following index from postgresql-upgrade-3.6-3.7.sql already
> exists:
>
> CREATE INDEX iOpExecOwnerOid
>    ON m_operation_execution (owner_oid);
>
> If you check the previous schema that was
> included with midPoint 3.6 (postgresql-upgrade-3.5-3.6.sql) you'll
> notice that this index was defined there.
>
> But this isn't even the real problem. The issue is that some tasks
> defined in midPoint 3.6 don't seem to have an owner reference, and
> midPoint 3.7 does not start with such a database.
>
> The relevant log lines, truncated:
>
> ERROR
> (com.evolveum.midpoint.task.quartzimpl.execution.TaskSynchronizer):
> Task Manager cannot synchronize task
> 00000000-0000-0000-0000-000000000007 due to schema exception..
>
> com.evolveum.midpoint.util.exception.SchemaException: Task
> 00000000-0000-0000-0000-000000000007 does not have an owner (missing
> ownerRef)
>
>
> The database confirms this:
>
>
> midpoint=# select name_norm, ownerref_targetoid from m_task;
>      name_norm     |          ownerref_targetoid
> ------------------+--------------------------------------
>   cleanup          | 00000000-0000-0000-0000-000000000002
>   trigger scanner  |
>   validity scanner |
> (3 rows)
>
>
> What I've tried so far:
>
> I did the terrible hack of just setting the ownerref_ fields to the
> same as in the "cleanup" task. However, when restarting midPoint, the
> data is overwritten, the records are missing ownerrefs again. This
> leads me to believe that midPoint deletes and recreates these records
> on its own during startup.
>
> How could I fix this? I am happy to supply more information.
>
> Cheers,
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180122/76f85854/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hfjiigeeoggealoc.png
Type: image/png
Size: 32303 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180122/76f85854/attachment.png>