THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Why I can see some DB workload even when Syncope is idle?
This happens because Syncope delegates to Quartz the handling of scheduled jobs.
Jobs take care of reporting, notification, propagation, synchronization from external resources and also user-defined actions.
I get the error "WorkflowException: ... No outgoing sequence flow..." when updating an user
This means that the given user has a workflow state for which no update is allowed.
Such constraints are contained in the default worklfow XML definition that can be extended an customized through the administration console.
I get the error "An error occurred while registering a ClassTransformer with PersistenceUnitInfo..." during startup
This is harmless according to OpenJPA.
In embedded mode I get the error "Deployable http://localhost:9080/cargocpc/index.html failed to finish deploying within the timeout period 120000. The Deployable state is thus unknown"
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:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<container>
to
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<container>
<timeout>180000</timeout>
Synchronization Task Execution "report" is not generated anymore, when a large number of users exist in the mysql DB (e.g. 1000+).
We can track the cause if we see errors in the core.log as follows:
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]
The cause is the JPA annotation @Lob (without any modifier) becomes "TEXT" column type in MySQL. MySQL features some more textual type variants, so if change the column definition in the TaskExec table message filed via SQL from TEXT to MEDIUMTEXT or LONGTEXT and then restart Syncope, permitting OpenJPA to update the change, you will overcome this limitation issue.
For example:
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 mysql ALTER command changes the "text" type value above to "mediumtext" type.
mysql> ALTER TABLE TaskExec MODIFY message mediumtext; Query OK, 99 rows affected (0.45 sec) Records: 99 Duplicates: 0 Warnings: 0
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) mysql>
