Table of Contents |
|
Why I can see some DB workload even when Syncope is idle?
...
This barely means that 2 minutes are not enough for setting up everything on the given hardware: you can configure this timeout by changing, in console/pom.xml
:
Code Block |
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<container>
|
to
Code Block |
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<container>
<timeout>180000</timeout>
|
...
We can track the cause if we see errors in the core.log
as follows:
Code Block |
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Data truncation: Data too long for column 'message' at row 1 {prepstmnt 1398507577 INSERT INTO TaskExec (id, endDate, message, startDate, status, TASK_ID) VALUES (?, ?, ?, ?, ?, ?)} [code=1406, state=22001]
|
...
However, MySQL features some more textual type variants, so when changing the message
column definition in the TaskExec
table from TEXT
to MEDIUMTEXT
or LONGTEXT
and then restart Syncope, permitting OpenJPA to get the change, you will overcome this limitation.
For example:
Code Block |
mysql> describe TaskExec;
+-----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| id | bigint(20) | NO | PRI | NULL | |
| endDate | datetime | YES | | NULL | |
| message | text | YES | | NULL | |
| startDate | datetime | YES | | NULL | |
| status | varchar(255) | NO | | NULL | |
| TASK_ID | bigint(20) | YES | MUL | NULL | |
+-----------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
|
The following command changes the TEXT
type value above to MEDIUMTEXT
type.
Code Block |
mysql> ALTER TABLE TaskExec MODIFY message MEDIUMTEXT;
|
Code Block |
mysql> describe TaskExec;
+-----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| id | bigint(20) | NO | PRI | NULL | |
| endDate | datetime | YES | | NULL | |
| message | mediumtext | YES | | NULL | |
| startDate | datetime | YES | | NULL | |
| status | varchar(255) | NO | | NULL | |
| TASK_ID | bigint(20) | YES | MUL | NULL | |
+-----------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
|
...
Note that this mechanism allows to add various details to synchronizing users: password, attributes, resources, roles, etc.
How to clean up task executions?
The easiest way to perform this cleaning is via the admin console, by leveraging the bulk action feature (leftmost checkbox column, available in many data tables, then click on the blue gear on the bottom and
choose the delete icon).
Via REST, task execution removal (for any kind of task: propagation, synchronization, scheduled, notification) can be performed as
Code Block |
title |
Spring MVC (<= 1.1.X) |
|
GET /rest/task/execution/delete/{executionId}
|
or
Code Block |
|
DELETE /cxf/tasks/executions/{executionId} (1.1.X)
DELETE /rest/tasks/executions/{executionId} (>= 1.2.X)
|
Consider anyway that task execution storage can be controlled by setting the trace level to NONE, FAILURES or SUMMARY instead of ALL (which is the default) on the corresponding Task or Notification.