<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Ramón,</p>
<p>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.</p>
<p>---<br>
</p>
<p>As for the missing ownerRef, it should not prevent midPoint from
starting. <br>
</p>
<p>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:</p>
<p><i>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. </i><i><b>Processing of 1 task(s) failed</b></i><i>.</i><br>
</p>
<p>(More tasks, in your case.) And the midPoint starts well.</p>
<p>---<br>
</p>
<p>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.<br>
</p>
<p>How does your log file continue? Could you post here more of it?</p>
<p>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:</p>
<p><img src="cid:part1.BD065584.D85EF76D@evolveum.com" alt=""></p>
<p>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.<br>
</p>
<p>Best regards,<br>
</p>
<pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
<div class="moz-cite-prefix">On 22.01.2018 12:19, Ramón Cahenzli
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180122121939.28d237cf@castle">
<pre wrap="">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,
</pre>
</blockquote>
<br>
</body>
</html>