Versions Compared

Old Version 11

changes.mady.by.user Francesco Chicchiriccò

Saved on

compared with

New Version 12

changes.mady.by.user Francesco Chicchiriccò

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel3
styledecimal

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
titleSpring MVC (<= 1.1.X)
GET /rest/task/execution/delete/{executionId}


or

Code Block
titleApache CXF
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.