UpdateTasks - Revision history

Dominik.epple: /* How to see all schemas? */

2017-12-12T14:46:06Z

How to see all schemas?

← Older revision		Revision as of 14:46, 12 December 2017
Line 109:		Line 109:
	\| 3 \| oxdb_14 \|		\| 3 \| oxdb_14 \|
	+------------+-----------+</nowiki>		+------------+-----------+</nowiki>

			Note: just to see all available schemas you probably are not interested in the db_pool_id. But to create input files for the "limited parallelity" method, you need these ids, therefore they are included in the statement.

	== Troubleshooting ==		== Troubleshooting ==

Dominik.epple: /* How to see all schemas? */

2017-12-12T14:45:04Z

How to see all schemas?

← Older revision		Revision as of 14:45, 12 December 2017
Line 92:		Line 92:
	) AS a ON d.db_pool_id=a.write_db_pool_id		) AS a ON d.db_pool_id=a.write_db_pool_id
	ORDER BY d.db_pool_id, CAST(SUBSTRING(db_schema, LOCATE('_', db_schema)+1) AS UNSIGNED);</nowiki>		ORDER BY d.db_pool_id, CAST(SUBSTRING(db_schema, LOCATE('_', db_schema)+1) AS UNSIGNED);</nowiki>

	~~If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.~~

	On a lab machine with 10 schemas on one DB instance the output looks like this:		On a lab machine with 10 schemas on one DB instance the output looks like this:

Dominik.epple: /* How to see all schemas? */

2017-12-12T14:44:35Z

How to see all schemas?

← Older revision		Revision as of 14:44, 12 December 2017
Line 87:		Line 87:
	Sample query (works in general as of writing this documentation, may break on schema updates in future):		Sample query (works in general as of writing this documentation, may break on schema updates in future):

	<nowiki>SELECT d.db_pool_id~~, SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port~~, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=a.write_db_pool_id ~~INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id=hp.id~~ ORDER BY d.db_pool_id, CAST(SUBSTRING(db_schema, LOCATE('_', db_schema)+1) AS UNSIGNED);</nowiki>		<nowiki>SELECT d.db_pool_id, a.db_schema FROM db_pool d
			INNER JOIN (
			SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema
			) AS a ON d.db_pool_id=a.write_db_pool_id
			ORDER BY d.db_pool_id, CAST(SUBSTRING(db_schema, LOCATE('_', db_schema)+1) AS UNSIGNED);</nowiki>

	If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.		If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.
Line 93:		Line 97:
	On a lab machine with 10 schemas on one DB instance the output looks like this:		On a lab machine with 10 schemas on one DB instance the output looks like this:

	<nowiki> +------~~------+---------+~~------+-----------+		<nowiki> +------------+-----------+
	\| db_pool_id ~~\| host \| port~~ \| db_schema \|		\| db_pool_id \| db_schema \|
	+------~~------+---------+~~------+-----------+		+------------+-----------+
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_5 \|		\| 3 \| oxdb_5 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_6 \|		\| 3 \| oxdb_6 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_7 \|		\| 3 \| oxdb_7 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_8 \|		\| 3 \| oxdb_8 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_9 \|		\| 3 \| oxdb_9 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_10 \|		\| 3 \| oxdb_10 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_11 \|		\| 3 \| oxdb_11 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_12 \|		\| 3 \| oxdb_12 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_13 \|		\| 3 \| oxdb_13 \|
	\| 3 ~~\| glb.lan \| 5507~~ \| oxdb_14 \|		\| 3 \| oxdb_14 \|
	+------~~------+---------+~~------+-----------+</nowiki>		+------------+-----------+</nowiki>

	== Troubleshooting ==		== Troubleshooting ==

Dominik.epple: /* Distributed execution of update tasks with limited parallelity */

2017-12-12T14:38:52Z

Distributed execution of update tasks with limited parallelity

← Older revision		Revision as of 14:38, 12 December 2017
Line 40:		Line 40:
	For large environments, we propose to prepare a distributed parallel execution of update tasks based on the assumption that each DB instance should be able to handle "some" (e.g. four) update tasks in parallel. The exact number depends on the DB hardware and needs to be determined by experience. But since the update tasks on different schemas operate independently we don't experience bottlenecks like lock contention from parallel execution of update tasks; it is only about available (CPU, IOPS, etc) resources.		For large environments, we propose to prepare a distributed parallel execution of update tasks based on the assumption that each DB instance should be able to handle "some" (e.g. four) update tasks in parallel. The exact number depends on the DB hardware and needs to be determined by experience. But since the update tasks on different schemas operate independently we don't experience bottlenecks like lock contention from parallel execution of update tasks; it is only about available (CPU, IOPS, etc) resources.

	Thus, the idea is to create text files, one per DB instance, with one schema per line. Use the SQL query given below in the "How to see all schemas" section for guidance how to obtain / create such a list. (Use the <code>-B -N</code> options and split manually the file per <code>db_pool_id</code> into separate files per DB instance. Delete all columns but the <code>db_schema</code> column.)		Thus, the idea is to create text files, one per DB instance, with one schema per line. Use the SQL query given below in the "How to see all schemas" section for guidance how to obtain / create such a list. (Use the <code>-B -N</code> options and split manually the file per <code>db_pool_id</code> into separate files per DB instance. Delete all columns but the <code>db_schema</code> column. Name the files like <code>schema-n.txt</code> where <code>n</code> is the DB pool id.)

	Use these separate, per-DB-instance files to run update tasks per DB instance in parallel using something like		Use these separate, per-DB-instance files to run update tasks per DB instance in parallel using something like

Dominik.epple: /* Distributed execution of update tasks with limited parallelity */

2017-12-12T14:37:34Z

Distributed execution of update tasks with limited parallelity

← Older revision		Revision as of 14:37, 12 December 2017
Line 46:		Line 46:
	<nowiki>cat schemas-3.txt \| xargs -n1 -P4 /opt/open-xchange/sbin/runupdate -n</nowiki>		<nowiki>cat schemas-3.txt \| xargs -n1 -P4 /opt/open-xchange/sbin/runupdate -n</nowiki>

	The <code>-P</code> switch to <code>xargs</code> defines parallel execution with 4 parallel processes.		The <code>-P</code> switch to <code>xargs</code> defines parallel execution with the given number of parallel processes.

	Spawn a command like this for every DB instance in parallel.		Spawn a command like this for every DB instance in parallel.

Dominik.epple: /* Distributed execution of update tasks with limited parallelity */

2017-12-12T14:36:44Z

Distributed execution of update tasks with limited parallelity

← Older revision		Revision as of 14:36, 12 December 2017
Line 38:		Line 38:
	=== Distributed execution of update tasks with limited parallelity ===		=== Distributed execution of update tasks with limited parallelity ===

	For large environments, we propose to prepare a distributed parallel execution of update tasks based on the assumption that each DB instance should be able to handle "some" (e.g. four) update tasks in parallel. The exact number depends on the DB hardware and needs to be determined by experience. But since the update tasks on different schemas operate independently we don't ~~effect~~ bottlenecks like lock contention from parallel execution of update tasks; it is only about available (CPU, IOPS, etc) resources.		For large environments, we propose to prepare a distributed parallel execution of update tasks based on the assumption that each DB instance should be able to handle "some" (e.g. four) update tasks in parallel. The exact number depends on the DB hardware and needs to be determined by experience. But since the update tasks on different schemas operate independently we don't experience bottlenecks like lock contention from parallel execution of update tasks; it is only about available (CPU, IOPS, etc) resources.

	Thus, the idea is to create text files, one per DB instance, with one schema per line. Use the SQL query given below in the "How to see all schemas" section for guidance how to obtain / create such a list. (Use the <code>-B -N</code> options and split manually the file per <code>db_pool_id</code> into separate files per DB instance. Delete all columns but the <code>db_schema</code> column.)		Thus, the idea is to create text files, one per DB instance, with one schema per line. Use the SQL query given below in the "How to see all schemas" section for guidance how to obtain / create such a list. (Use the <code>-B -N</code> options and split manually the file per <code>db_pool_id</code> into separate files per DB instance. Delete all columns but the <code>db_schema</code> column.)

Dominik.epple: uire

2017-12-12T14:36:14Z

uire

← Older revision		Revision as of 14:36, 12 December 2017
Line 1:		Line 1:
	= Update Task management in Open-Xchange =		= Update Task management in Open-Xchange =

	== ~~What is an Update Task?~~ ==		== Overview ==

			OX App Suite occasionally requires updates to the DB schemas via so-called update tasks. Usually an update task is something like adding tables, adding columns to tables, adding incides to tables, dropping columns, dropping tables, and so on.

	~~An update task contains one or more operations on the Open-Xchange mysql database.~~
	Update tasks take care to apply changes to database tables which are required for new features		Update tasks take care to apply changes to database tables which are required for new features
	or bugfixes.		or bugfixes.

	== ~~When are Update Tasks applied?~~ ==		Usually update tasks are only included in feature updates to OX App Suite (and not bugfix releases), but if a bugfix requires an update task, we will ship an update task also with a bugfix release.

			== Running update tasks ==

			=== Automatically ===

	Update tasks are applied when either the first user logs in to the OX UI or when triggered manually.		Update tasks are applied when either the first user logs in to the OX UI or when triggered manually.
Line 13:		Line 18:
	schema.		schema.

	~~== Tools~~ to ~~maintain Update Tasks ==~~		We highly recommend to avoid this automatic update task execution on any real world production site in order to not overwhelm the databases with massive amounts of parallel running update tasks. See the [[Running_a_cluster#The_Big_Picture]] page (and the following sections of this page) for more background information.

	=== Run update tasks on all schemas serially ===		=== Run update tasks on all schemas serially ===

			Since 7.8.3 we offer a tool to execute all update tasks serially, one by one.

	$ /opt/open-xchange/sbin/runallupdate		$ /opt/open-xchange/sbin/runallupdate

			In large environments with multiple database instances this probably wastes a lot of speedup potential by parallelizing since update tasks can at least be parallelized by one per DB instance, probably also to (some small integer number) per DB instance. We'll cover how to do so in the following sections.

	=== Run update tasks on one schema ===		=== Run update tasks on one schema ===

			Before 7.8.3 the only tool we offered to trigger update tasks was <code>runupdate</code> which can run update tasks for a given schema.

	$ /opt/open-xchange/sbin/runupdate -n schema		$ /opt/open-xchange/sbin/runupdate -n schema

			This tool can also serve as component for some advanced combination of serial and parallel execution of update tasks to achive something like "execute N update tasks per DB instance in parallel".

			=== Distributed execution of update tasks with limited parallelity ===

			For large environments, we propose to prepare a distributed parallel execution of update tasks based on the assumption that each DB instance should be able to handle "some" (e.g. four) update tasks in parallel. The exact number depends on the DB hardware and needs to be determined by experience. But since the update tasks on different schemas operate independently we don't effect bottlenecks like lock contention from parallel execution of update tasks; it is only about available (CPU, IOPS, etc) resources.

			Thus, the idea is to create text files, one per DB instance, with one schema per line. Use the SQL query given below in the "How to see all schemas" section for guidance how to obtain / create such a list. (Use the <code>-B -N</code> options and split manually the file per <code>db_pool_id</code> into separate files per DB instance. Delete all columns but the <code>db_schema</code> column.)

			Use these separate, per-DB-instance files to run update tasks per DB instance in parallel using something like

			<nowiki>cat schemas-3.txt \| xargs -n1 -P4 /opt/open-xchange/sbin/runupdate -n</nowiki>

			The <code>-P</code> switch to <code>xargs</code> defines parallel execution with 4 parallel processes.

			Spawn a command like this for every DB instance in parallel.

			You end up with (4xN) parallel runupdate processes, where N is the number of DB instances.

			== Diagnosis / Monitoring ==

	=== List executed update tasks for a given schema ===		=== List executed update tasks for a given schema ===
Line 56:		Line 87:
	Sample query (works in general as of writing this documentation, may break on schema updates in future):		Sample query (works in general as of writing this documentation, may break on schema updates in future):

	<nowiki>SELECT SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=a.write_db_pool_id INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id=hp.id;</nowiki>		<nowiki>SELECT d.db_pool_id, SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=a.write_db_pool_id INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id=hp.id ORDER BY d.db_pool_id, CAST(SUBSTRING(db_schema, LOCATE('_', db_schema)+1) AS UNSIGNED);</nowiki>

	If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.		If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.

	On a lab machine with 10 schemas on one DB instance ~~this~~ looks like:		On a lab machine with 10 schemas on one DB instance the output looks like this:

			<nowiki> +------------+---------+------+-----------+
			\| db_pool_id \| host \| port \| db_schema \|
			+------------+---------+------+-----------+
			\| 3 \| glb.lan \| 5507 \| oxdb_5 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_6 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_7 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_8 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_9 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_10 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_11 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_12 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_13 \|
			\| 3 \| glb.lan \| 5507 \| oxdb_14 \|
			+------------+---------+------+-----------+</nowiki>

	<nowiki>SELECT SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=~~a.write_db_pool_id INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id~~=~~hp.id;~~		== Troubleshooting ==
	~~+---------+------+-----------+~~
	~~\| host \| port \| db_schema \|~~
	~~+---------+------+-----------+~~
	~~\| glb.lan \| 5507 \| oxdb_9 \|~~
	~~\| glb.lan \| 5507 \| oxdb_8 \|~~
	~~\| glb.lan \| 5507 \| oxdb_7 \|~~
	~~\| glb.lan \| 5507 \| oxdb_6 \|~~
	~~\| glb.lan \| 5507 \| oxdb_5 \|~~
	~~\| glb.lan \| 5507 \| oxdb_14 \|~~
	~~\| glb.lan \| 5507 \| oxdb_13 \|~~
	~~\| glb.lan \| 5507 \| oxdb_12 \|~~
	~~\| glb.lan \| 5507 \| oxdb_11 \|~~
	~~\| glb.lan \| 5507 \| oxdb_10 \|~~
	~~+---------+------+-----------+~~
	~~10 rows in set (0.00 sec)</nowiki>~~

	== What if I have Update Tasks that are LOCKED? ==		=== What if I have Update Tasks that are LOCKED? ===

	If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>LOCKED</i> in the <i>taskName</i> row,		If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>LOCKED</i> in the <i>taskName</i> row,
Line 115:		Line 146:
	mysql> UPDATE version SET locked=0;		mysql> UPDATE version SET locked=0;

	== What if I have Update Tasks that are in status false? ==		=== What if I have Update Tasks that are in status false? ===

	If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>false</i> in the <i>successful</i> row,		If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>false</i> in the <i>successful</i> row,

Dominik.epple: /* Tools to maintain Update Tasks */

2017-12-12T12:40:46Z

Tools to maintain Update Tasks

← Older revision		Revision as of 12:40, 12 December 2017
Line 15:		Line 15:
	== Tools to maintain Update Tasks ==		== Tools to maintain Update Tasks ==

	~~$ /opt/open-xchange/sbin/runupdate -n schema~~		=== Run update tasks on all schemas serially ===

	~~runs update tasks in specified schema~~		$ /opt/open-xchange/sbin/runallupdate

	~~$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n~~ schema		=== Run update tasks on one schema ===

	~~lists executed update tasks in specified~~ schema		$ /opt/open-xchange/sbin/runupdate -n schema

	=== ~~How to see all schemas?~~ ===		=== List executed update tasks for a given schema ===

	~~Note: you need to have your account names and passwords at hand.~~		$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n schema

	~~run~~

	$ /opt/open-xchange/sbin/~~listdatabase~~ -~~A oxadminmaster -P secret~~
	~~id name hostname master mid weight maxctx curctx hlimit max inital~~
	~~3 oxdatabase localhost true 0 100 1000 12 true 100 0~~

	~~to check your database~~ schema ~~prefix. In this case it is <tt>oxdatabase</tt>~~

	~~run~~

	~~$ echo show databases \| mysql -uopenexchange -psecret \| grep oxdata~~
	~~oxdatabase_5~~

	~~so we have just one schema named <tt>oxdatabase_5</tt>.~~

	~~Now you could check the status of update tasks on that schema~~:		Sample output:

	$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n oxdatabase_5		<nowiki>$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n oxdatabase_5
	taskName successful lastModified		taskName successful lastModified
	[...]		[...]
Line 63:		Line 48:
	com.openexchange.contact.storage.rdb.sql.AddFilenameColumnTask true 2014-02-02 11:37:47 MEZ		com.openexchange.contact.storage.rdb.sql.AddFilenameColumnTask true 2014-02-02 11:37:47 MEZ
	com.openexchange.groupware.update.tasks.GenconfAttributesStringsAddUuidUpdateTask true 2014-02-02 11:37:48 MEZ		com.openexchange.groupware.update.tasks.GenconfAttributesStringsAddUuidUpdateTask true 2014-02-02 11:37:48 MEZ
	[...]		[...]</nowiki>

			=== How to see all schemas? ===

			The database schemas are not exposed via OX tooling. You need to read them from the configdb. In principle you're looking for <code>db_schema</code> entries from the <code>context_server2db_pool</code> table and join that with corresponding lines from the <code>db_pool</code> table to get the database instance the schema is living on.

			Sample query (works in general as of writing this documentation, may break on schema updates in future):

			<nowiki>SELECT SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=a.write_db_pool_id INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id=hp.id;</nowiki>

			If you also want to see login name and password for the given db hosts, add <code>d.login, d.password</code> to the fields returned by the query.

			On a lab machine with 10 schemas on one DB instance this looks like:

			<nowiki>SELECT SUBSTRING(hp.host_port, 1, LOCATE(':', hp.host_port)-1) AS host, SUBSTRING(hp.host_port, LOCATE(':', hp.host_port)+1) AS port, a.db_schema FROM db_pool d INNER JOIN (SELECT write_db_pool_id, db_schema FROM context_server2db_pool GROUP BY db_schema) AS a ON d.db_pool_id=a.write_db_pool_id INNER JOIN (SELECT d.db_pool_id as id, REPLACE(SUBSTRING(d.url, 1, LOCATE('/?', d.url)-1), 'jdbc:mysql://', '') AS host_port FROM db_pool d) AS hp ON d.db_pool_id=hp.id;
			+---------+------+-----------+
			\| host \| port \| db_schema \|
			+---------+------+-----------+
			\| glb.lan \| 5507 \| oxdb_9 \|
			\| glb.lan \| 5507 \| oxdb_8 \|
			\| glb.lan \| 5507 \| oxdb_7 \|
			\| glb.lan \| 5507 \| oxdb_6 \|
			\| glb.lan \| 5507 \| oxdb_5 \|
			\| glb.lan \| 5507 \| oxdb_14 \|
			\| glb.lan \| 5507 \| oxdb_13 \|
			\| glb.lan \| 5507 \| oxdb_12 \|
			\| glb.lan \| 5507 \| oxdb_11 \|
			\| glb.lan \| 5507 \| oxdb_10 \|
			+---------+------+-----------+
			10 rows in set (0.00 sec)</nowiki>

	== What if I have Update Tasks that are LOCKED? ==		== What if I have Update Tasks that are LOCKED? ==

Choeger: /* How to see all schemas? */

2014-02-04T12:49:28Z

How to see all schemas?

← Older revision		Revision as of 12:49, 4 February 2014
Line 46:		Line 46:
	$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n oxdatabase_5		$ /opt/open-xchange/sbin/listExecutedUpdateTasks -n oxdatabase_5
	taskName successful lastModified		taskName successful lastModified
	com.openexchange.groupware.~~calendar~~.update.~~AlterCreatingDate~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		[...]
	com.openexchange.~~usm~~.~~database~~.ox.update.~~ChangeCollationUpdateTask~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		LOCKED true 2014-02-02 11:35:49 MEZ
	com.openexchange.~~contact~~.~~storage~~.~~rdb~~.~~sql.CorrectNumberOfImagesTask~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.jslob.storage.db.groupware.DBJSlobCreateTableTask true 2014-02-02 11:35:52 MEZ
	com.openexchange.groupware.update.tasks.~~AttachmentCountUpdateTask~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.groupware.update.tasks.RemoveUnnecessaryIndexes true 2014-02-02 11:35:54 MEZ
	com.openexchange.groupware.update.tasks.~~CreateTableVersion~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.groupware.update.tasks.CreateIcalPrincipalPrimaryKeyTask true 2014-02-02 11:35:54 MEZ
	com.openexchange.groupware.update.tasks.~~ContactAddUIDValueTask~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.groupware.update.tasks.MailAccountAddArchiveTask true 2014-02-02 11:35:54 MEZ
	com.openexchange.groupware.update.tasks.~~ClearOrphanedInfostoreDocuments~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.groupware.update.tasks.GenconfAttributesBoolsAddUuidUpdateTask true 2014-02-02 11:35:54 MEZ
	com.openexchange.groupware.update.tasks.~~FacebookCrawlerSubscriptionRemoverTask~~ true ~~2012~~-09-~~19 05~~:32:~~05 EDT~~		com.openexchange.groupware.update.tasks.HeaderCacheDropFKTask true 2014-02-02 11:35:55 MEZ
			com.openexchange.groupware.update.tasks.ResourceClearDelTablesTask true 2014-02-02 11:35:55 MEZ
			com.openexchange.groupware.update.tasks.AddUUIDForUpdateTaskTable true 2014-02-02 11:35:55 MEZ
			com.openexchange.groupware.update.tasks.MailAccountAddReplyToTask true 2014-02-02 11:35:55 MEZ
			com.openexchange.groupware.tasks.database.TasksModifyCostColumnTask true 2014-02-02 11:35:59 MEZ
			com.openexchange.groupware.update.tasks.PrgContactsLinkageAddUuidUpdateTask true 2014-02-02 11:36:00 MEZ
			com.openexchange.ajax.requesthandler.converters.preview.cache.groupware.PreviewCacheCreateTableTask true 2014-02-02 11:36:00 MEZ
			com.openexchange.groupware.update.tasks.InfostoreExtendReservedPathsNameTask true 2014-02-02 11:36:00 MEZ
			com.openexchange.contact.storage.rdb.sql.AddFilenameColumnTask true 2014-02-02 11:37:47 MEZ
			com.openexchange.groupware.update.tasks.GenconfAttributesStringsAddUuidUpdateTask true 2014-02-02 11:37:48 MEZ
	[...]		[...]

Choeger: /* What if I have Update Tasks that are LOCKED? */

2014-02-04T12:48:28Z

What if I have Update Tasks that are LOCKED?

← Older revision		Revision as of 12:48, 4 February 2014
Line 58:		Line 58:
	== What if I have Update Tasks that are LOCKED? ==		== What if I have Update Tasks that are LOCKED? ==

	If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>LOCKED</i> in the <i>~~successful~~</i> row,		If the command <tt>listExecutedUpdateTasks</tt> lists tasks that have the word <i>LOCKED</i> in the <i>taskName</i> row,
	these tasks could not be completed. This usually happens when Open-Xchange is being stopped while the update tasks are still running.		these tasks could not be completed. This usually happens when Open-Xchange is being stopped while the update tasks are still running.