MoodleDocs - User contributions [en]

Development:Profiling PHP

2010-11-10T17:47:50Z

Mjollnir:

{{stub}}

Suggestion, please look into xhprof (I saw the following talk about it: https://docs.google.com/present/view?id=dcbkgbgf_45fbg3rnmk&)

==See also==

* [http://moodle.org/mod/forum/discuss.php?d=162045 Forum thread about profiling Moodle 2.0]

{{CategoryDeveloper}}

Development:MNET 2.0

2010-03-16T08:50:56Z

Mjollnir: /* Method signatures */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

See [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&&pid=10011&fixfor=10122&status=5&status=6&component=10162&sorter/field=updated&sorter/order=DESC this list] for all closed 2.0 MNET bugs.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

'''Important: this means that you ''must'' write phpdocs in the correct format, otherwise a php warning will be generated'''

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

=== Removal of all MNET globals ===

There were two regularly used MNET globals, $MNET and $MNET_REMOTE_CLIENT. These have both been removed, and replaced with get_mnet_environment and get_mnet_remote_client functions, which are available in the global scope. The mnet remote client object is '''only''' set at the start of mnet/xmlrpc/server.php, and if it is attempted to be accessed outside of the mnet xmlrpc server environment, an error will occur. This will be a debugging() level error in the case of trying to get the mnet remote client object, and an exception if trying to set it.

The last MNET global was only used in one place, and it related to the jump url of a given user. This was used in rewriting urls in a preg_replace_callback in email_to_user. This has been replaced with no global and a partially bound function. PHP has no native partial binding, but a workaround has been recently added to HEAD.

See the following bugs about this:

* MDL-21130
* MDL-21276
* MDL-21255

=== Conditional MNET environment bootstrapping ===

Previously any time you included mnet/lib.php, the mnet environment was bootstrapped. This is not ideal as it adds a lot of unnecessary overhead. Now any time you need any bit of the mnet environment, you must do $mnet = get_mnet_environment. Note that this replaces the old $MNET global, but it is no longer always bootstrapped for you.

See the following bug about this:

* MDL-21276

=== Removal of library code from mnet/xmlrpc/server.php ===

mnet/xmlrpc/server.php used to contain both functional code and library code, and I always found it annoying reading through what should have been a simple script, which was hundreds of lines long, so I moved all the functions into mnet/xmlrpc/serverlib.php in case they needed to be reused.

=== Better debugging ===

There is now an mnet_debug function which will print to the error log. MNET previously used trigger_error in places, which raises a PHP-level notice/warning/error. This is not helpful in all cases, because of ini settings, or log targets. In particular if php errors are going to STDOUT, this will cause problems in the XMLRPC responses. The mnet_debug function takes any sort of argument (it will recursively call itself for objects and arrays) and a debuglevel. This is controlled by $CFG->mnet_rpcdebug, which is a config.php only setting (and has been there since before the MNET overhaul)

== Administrative changes ==

=== New Networking Test Client ===

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

=== Removal of 'auto create users' configuration option ===

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

=== Reworked MNET administration screens ===

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256

Development:MNET 2.0

2010-02-16T23:50:02Z

Mjollnir: /* Introduction */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

See [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&&pid=10011&fixfor=10122&status=5&status=6&component=10162&sorter/field=updated&sorter/order=DESC this list] for all closed 2.0 MNET bugs.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

=== Removal of all MNET globals ===

There were two regularly used MNET globals, $MNET and $MNET_REMOTE_CLIENT. These have both been removed, and replaced with get_mnet_environment and get_mnet_remote_client functions, which are available in the global scope. The mnet remote client object is '''only''' set at the start of mnet/xmlrpc/server.php, and if it is attempted to be accessed outside of the mnet xmlrpc server environment, an error will occur. This will be a debugging() level error in the case of trying to get the mnet remote client object, and an exception if trying to set it.

The last MNET global was only used in one place, and it related to the jump url of a given user. This was used in rewriting urls in a preg_replace_callback in email_to_user. This has been replaced with no global and a partially bound function. PHP has no native partial binding, but a workaround has been recently added to HEAD.

See the following bugs about this:

* MDL-21130
* MDL-21276
* MDL-21255

=== Conditional MNET environment bootstrapping ===

Previously any time you included mnet/lib.php, the mnet environment was bootstrapped. This is not ideal as it adds a lot of unnecessary overhead. Now any time you need any bit of the mnet environment, you must do $mnet = get_mnet_environment. Note that this replaces the old $MNET global, but it is no longer always bootstrapped for you.

See the following bug about this:

* MDL-21276

=== Removal of library code from mnet/xmlrpc/server.php ===

mnet/xmlrpc/server.php used to contain both functional code and library code, and I always found it annoying reading through what should have been a simple script, which was hundreds of lines long, so I moved all the functions into mnet/xmlrpc/serverlib.php in case they needed to be reused.

=== Better debugging ===

There is now an mnet_debug function which will print to the error log. MNET previously used trigger_error in places, which raises a PHP-level notice/warning/error. This is not helpful in all cases, because of ini settings, or log targets. In particular if php errors are going to STDOUT, this will cause problems in the XMLRPC responses. The mnet_debug function takes any sort of argument (it will recursively call itself for objects and arrays) and a debuglevel. This is controlled by $CFG->mnet_rpcdebug, which is a config.php only setting (and has been there since before the MNET overhaul)

== Administrative changes ==

=== New Networking Test Client ===

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

=== Removal of 'auto create users' configuration option ===

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

=== Reworked MNET administration screens ===

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256

Development:MNET 2.0

2010-02-16T23:49:16Z

Mjollnir:

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

See [ http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&&pid=10011&fixfor=10122&status=5&status=6&component=10162&sorter/field=updated&sorter/order=DESC this list] for all closed 2.0 MNET bugs.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

=== Removal of all MNET globals ===

There were two regularly used MNET globals, $MNET and $MNET_REMOTE_CLIENT. These have both been removed, and replaced with get_mnet_environment and get_mnet_remote_client functions, which are available in the global scope. The mnet remote client object is '''only''' set at the start of mnet/xmlrpc/server.php, and if it is attempted to be accessed outside of the mnet xmlrpc server environment, an error will occur. This will be a debugging() level error in the case of trying to get the mnet remote client object, and an exception if trying to set it.

The last MNET global was only used in one place, and it related to the jump url of a given user. This was used in rewriting urls in a preg_replace_callback in email_to_user. This has been replaced with no global and a partially bound function. PHP has no native partial binding, but a workaround has been recently added to HEAD.

See the following bugs about this:

* MDL-21130
* MDL-21276
* MDL-21255

=== Conditional MNET environment bootstrapping ===

Previously any time you included mnet/lib.php, the mnet environment was bootstrapped. This is not ideal as it adds a lot of unnecessary overhead. Now any time you need any bit of the mnet environment, you must do $mnet = get_mnet_environment. Note that this replaces the old $MNET global, but it is no longer always bootstrapped for you.

See the following bug about this:

* MDL-21276

=== Removal of library code from mnet/xmlrpc/server.php ===

mnet/xmlrpc/server.php used to contain both functional code and library code, and I always found it annoying reading through what should have been a simple script, which was hundreds of lines long, so I moved all the functions into mnet/xmlrpc/serverlib.php in case they needed to be reused.

=== Better debugging ===

There is now an mnet_debug function which will print to the error log. MNET previously used trigger_error in places, which raises a PHP-level notice/warning/error. This is not helpful in all cases, because of ini settings, or log targets. In particular if php errors are going to STDOUT, this will cause problems in the XMLRPC responses. The mnet_debug function takes any sort of argument (it will recursively call itself for objects and arrays) and a debuglevel. This is controlled by $CFG->mnet_rpcdebug, which is a config.php only setting (and has been there since before the MNET overhaul)

== Administrative changes ==

=== New Networking Test Client ===

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

=== Removal of 'auto create users' configuration option ===

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

=== Reworked MNET administration screens ===

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256

Development:MNET 2.0

2010-02-16T23:45:38Z

Mjollnir: /* Other code changes */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

=== Removal of all MNET globals ===

There were two regularly used MNET globals, $MNET and $MNET_REMOTE_CLIENT. These have both been removed, and replaced with get_mnet_environment and get_mnet_remote_client functions, which are available in the global scope. The mnet remote client object is '''only''' set at the start of mnet/xmlrpc/server.php, and if it is attempted to be accessed outside of the mnet xmlrpc server environment, an error will occur. This will be a debugging() level error in the case of trying to get the mnet remote client object, and an exception if trying to set it.

The last MNET global was only used in one place, and it related to the jump url of a given user. This was used in rewriting urls in a preg_replace_callback in email_to_user. This has been replaced with no global and a partially bound function. PHP has no native partial binding, but a workaround has been recently added to HEAD.

See the following bugs about this:

* MDL-21130
* MDL-21276
* MDL-21255

=== Conditional MNET environment bootstrapping ===

Previously any time you included mnet/lib.php, the mnet environment was bootstrapped. This is not ideal as it adds a lot of unnecessary overhead. Now any time you need any bit of the mnet environment, you must do $mnet = get_mnet_environment. Note that this replaces the old $MNET global, but it is no longer always bootstrapped for you.

See the following bug about this:

* MDL-21276

=== Removal of library code from mnet/xmlrpc/server.php ===

mnet/xmlrpc/server.php used to contain both functional code and library code, and I always found it annoying reading through what should have been a simple script, which was hundreds of lines long, so I moved all the functions into mnet/xmlrpc/serverlib.php in case they needed to be reused.

=== Better debugging ===

There is now an mnet_debug function which will print to the error log. MNET previously used trigger_error in places, which raises a PHP-level notice/warning/error. This is not helpful in all cases, because of ini settings, or log targets. In particular if php errors are going to STDOUT, this will cause problems in the XMLRPC responses. The mnet_debug function takes any sort of argument (it will recursively call itself for objects and arrays) and a debuglevel. This is controlled by $CFG->mnet_rpcdebug, which is a config.php only setting (and has been there since before the MNET overhaul)

== Administrative changes ==

=== New Networking Test Client ===

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

=== Removal of 'auto create users' configuration option ===

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

=== Reworked MNET administration screens ===

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256

Development:MNET 2.0

2010-02-16T23:26:46Z

Mjollnir: /* Administrative changes */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

== Administrative changes ==

=== New Networking Test Client ===

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

=== Removal of 'auto create users' configuration option ===

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

=== Reworked MNET administration screens ===

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256

Development:MNET 2.0

2010-02-16T04:22:18Z

Mjollnir: /* Administrative changes */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

== Administrative changes ==

=== New Networking Test Client ===

=== Removal of 'auto create users' configuration option ===

Developmnet:MNET 2.0

2010-02-16T04:21:03Z

Mjollnir: Developmnet:MNET 2.0 moved to Development:MNET 2.0

#REDIRECT [[Development:MNET 2.0]]

Development:MNET 2.0

2010-02-16T04:21:03Z

Mjollnir: Developmnet:MNET 2.0 moved to Development:MNET 2.0

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

== Administrative changes ==

Development:MNET 2.0

2010-02-16T03:53:23Z

Mjollnir: /* Method signatures */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

See the following bugs about this:

* MDL-21261

== Other code changes ==

== Administrative changes ==

Development:MNET 2.0

2010-02-16T03:47:36Z

Mjollnir: /* Plugins registering MNET services */

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

</code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

== Other code changes ==

== Administrative changes ==

Development:MNET 2.0

2010-02-16T03:47:06Z

Mjollnir:

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

<code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new''' .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us '''some''' information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

<code php>
array(
array(
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */
)
</code>

it now looks like this:

<code php>
array(
'parameters' => array(
array(
'name' => 'token',
'type' => 'string',
'description' => 'something here',
),
array(
/* ... */
),
/* ... */,
),
'return' => array(
'type' => 'string',
'description' => 'something here',
),
)
</code>

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used '''within Moodle''', however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

== Other code changes ==

== Administrative changes ==

Development:MNET 2.0

2010-02-16T03:37:05Z

Mjollnir:

== Introduction ==

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

== Backwards Compatibility Breaks ==

=== Plugins registering MNET services ===

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

<code php>

$publishes = array(
'pf' => array(
'apiversion' => 1,
'classname' => 'portfolio_plugin_mahara',
'filename' => 'lib.php',
'methods' => array(
'fetch_file'
),
),
);
$subscribes = array(
'pf' => array(
'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
'send_content_ready' => 'portfolio/mahara/lib.php/send_content_ready',
),
);

<code>

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. '''This is new'''.

See the following bugs about this:

* MDL-21261
* MDL-16269
* MDL-16277

=== Method signatures ===

== Other code changes ==

== Administrative changes ==

Development:MNET 2.0

2010-02-16T03:24:24Z

Mjollnir: New page: == Introduction == This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective. There are still...

Development:MNet Errors

2010-01-27T00:49:23Z

Mjollnir: /* 708, "nosuchclass" = */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

=== 7000, "unknownerror" ===

For some reason the xmlrpc request cannot be processed. Generic failure message.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

This happens when the function is found, but not allowed (either not published to this host, or disabled)

=== 708, "nosuchclass" ===

This happens when the class couldn't be found - probably would only happen if someone hacked code, as the mnet function installer checks this before putting rpc methods in the database.

=== 709, "classerror" ===

This happens when the class is found, but cannot be constructed - an error was thrown.

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-27T00:44:27Z

Mjollnir: /* Dispatch errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

=== 7000, "unknownerror" ===

For some reason the xmlrpc request cannot be processed. Generic failure message.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

This happens when the function is found, but not allowed (either not published to this host, or disabled)

=== 708, "nosuchclass" ====

This happens when the class couldn't be found - probably would only happen if someone hacked code, as the mnet function installer checks this before putting rpc methods in the database.

=== 709, "classerror" ===

This happens when the class is found, but cannot be constructed - an error was thrown.

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-27T00:32:21Z

Mjollnir: /* Dispatch errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

=== 7000, "unknownerror" ===

For some reason the xmlrpc request cannot be processed. Generic failure message.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

This happens when the function is found, but not allowed (either not published to this host, or disabled)

=== 708, "nosuchclass" ====

This happens when the class couldn't be found - probably would only happen if someone hacked code, as the mnet function installer checks this before putting rpc methods in the database.

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-26T22:50:55Z

Mjollnir: /* 707, "forbidden-function" */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

=== 7000, "unknownerror" ===

For some reason the xmlrpc request cannot be processed. Generic failure message.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

This happens when the function is found, but not allowed (either not published to this host, or disabled)

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-26T21:59:50Z

Mjollnir: /* System/Verification errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

=== 7000, "unknownerror" ===

For some reason the xmlrpc request cannot be processed. Generic failure message.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-13T01:01:45Z

Mjollnir: /* Enrolment errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ===

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-13T00:57:38Z

Mjollnir: /* Enrolment errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

=== 5011, "couldnotcreateuser" ===

This is triggered when a user is requested to be enrolled in a course, but the user doesn't exist and an error happens trying to create their record

=== 5012, "coursenotfound" ===

This is triggered when a user is requested to be enrolled in a course, but the course doesn't exist

=== 5013, "courseunavailable" ===

This is triggered when a user is requested to be enrolled in a course, but the course isn't in the whitelist of available courses

=== 5014, "usernotfound" ===

This is triggered when a user is requested to be unenrolled from a course, but the user isn't found

=== 5015, "couldnotunenrol" ====

This is triggered if role_unassign fails

=== 5016, "couldnotenrol" ===

This is triggered if enrol_into_course fails

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== 9012, "usernotfound" ===

This is triggered when the local user is not registered in the remote Moodle site.

=== 9013, "usercannotaccess" ===

This is triggered when the local user cannot access to this file on the remote Moodle site.

=== 9014, "failtoretrievelist" ===

This is triggered when no file list could be retrieved from the remote Moodle site.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-11T04:13:08Z

Mjollnir:

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

=== others ===

TODO Jerome or someone else

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-11T04:09:55Z

Mjollnir: /* Repository errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

TODO Jerome or someone else

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-11T04:09:05Z

Mjollnir: /* Portfolio errors */

== Introduction ==

This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically pluggable, this does not cover all exhaustive cases, just ones that are included in the core Moodle distribution.

== System/Verification errors ==

=== 712, "phperror" ===

This is called from the main mnet xmlrpc server (mnet/xmlrpc/server.php) when $_SERVER is unset.

=== 7025 ===

This is triggered when the peer used an older public key. This sends the xmlrpc server fault, with 7025 as the code, and the current public key as the text of the error message.

=== 7021, "forbidden-transport" ===

This is triggered if a non-encrypted request is sent, and plaintext is disallowed (plaintext can be enabled for trusted hosts within a designated subnet)

=== 711, "verifysignature-error" ===

This is triggered if a request wasn't signed

=== 710, "verifysignature-invalid" ===

This is triggered if a request was signed, but not able to be verified

=== 7020, "wrong-wwwroot" ===

This is triggered if the host record is unable to be found, based on the wwwroot inside the xmlrpc request. This can sometimes happen if you use www.mysite.com and mysite.com

=== 7023, "encryption-invalid" ===

This is triggered if Moodle can't decrypt the message either with the current key, or with any of the keys in the history.

=== 7014, "nosuchmethod" ===

This is triggered in the case that a class method has been requested, a new object has been constructed, but then the method cannot be called on the object.

Note that 7014 is also purportedly triggered with a "nosuchfunction" message in mnet_server_invoke_method, but it is in a non-executable piece of code.

=== 7015, "nosuchfunction" ===

This is triggered in the case that the class doesn't export a list of published mnet methods, in either the case of the requested method being static, or not.

== Dispatch errors ==

=== 713, "nosuchfunction" ===

This is triggered if the function given in the xmlrpc request doesn't match the regular expression of allowed function calls (which must be of the form auth/mnet/auth.php/function_name)

=== 704, "nosuchservice" ===

This is triggered if "Networking" is disabled in Admin -> Advanced Features, or $CFG->mnet_dispatcher_mode is "off".

=== 7018, "nosuchfunction" ===

This is triggered if the xmlrpc request was for a system method (eg "listMethods", etc), but it wasn't in the list of allowed systemcalls. The complete list of system calls are:

* listMethods
* methodSignature
* methodHelp
* listServices
* listFiles
* retrieveFile
* keyswap

=== 7012, "nosuchfunction" ===

This is the generic error code for the inability to find a function.

=== 7019, "nosuchfunction" ===

This is triggered in mnet_system() if a system method has been called, but it's not listMethods, methodSignature, methodHelp, or listServices. It looks as though listFiles or retrieveFile are not implemented, even though they are registered to mnet_system in the mnet_server_dispatch() function.

This is also triggered if mnet_permit_rpc_call returns a non-zero error code that hasn't already been trapped by one of the RPC_ constants defined in mnet/lib.php (which have their own error codes)

=== 705, "nosuchfile" ===

This is triggered if the file requested cannot be found (eg auth/mnet/lib.php instead of auth/mnet/auth.php)

=== 706, "nosuchfunction" ===

This is triggered if the xmlrpc request is for a function (rather than a static method or class method), and it cannot be called (eg function_exists fails)

=== 707, "forbidden-function" ===

There isn't any code that throws this error case

== Authentication errors ==

=== 702, "nosuchfunction" ===

This is triggered when the request was for an authentication method, but the authentication plugin requested wasn't enabled.

=== 7013, "nosuchfunction" ===

This is triggered when a class or static method has been requested, but the class could not be founded (eg class_exists fails). The error message should be renamed in this case.

=== 1, "authfail_nosessionexists" ===

This is triggered when there's no record in the mnet_session table for the given token and useragent.

=== 2, "authfail_sessiontimedout" ===

This is triggered when there is a session, but confirmation has already timed out

=== 3, "authfail_usermismatch" ===

This is triggered when Moodle can't find the user that the mnet session has been set up for. This is a weird error, but could possibly happen if the user was deleted between the mnet session being created, and confirmed.

== Enrolment errors ==

=== 703, "nosuchfunction" ===

This is triggered when the request was for an enrolment method, but the enrolment plugin requested wasn't enabled.

== Portfolio errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a portfolio plugin. This should be changed to check that the portfolio plugin is enabled.

=== 8009, "mnet_notoken" ===

This is triggered when Mahara requests a portfolio file from Moodle and Moodle can't find a token in the transfer queue.

=== 8010, "mnet_noid" ===

This is triggered when Mahara requests a file, the queue record is found, but the transfer information cannot be rewoken (which can happen if permissions have changed or settings have changed in the meantime, or the transfer is expired)

=== 8011, "mnet_wronghost" ===

This is trigered if the xmlrpc request comes from a different host than the queue record has been saved against

=== 8012, "mnet_nofile" ===

This is triggered when Mahara requests a file, and Moodle can't find it

=== 8013, "mnet_nofilecontents" ===

This is triggered when Mahara requests a file, Moodle portfolio records know which file to send, but the Files API throws an exception, or the file is empty.

== Repository errors ==

=== 7012, "nosuchfunction" ===

This is triggered when an invalid filename is sent for a repository plugin. This should be changed to check that the repository plugin is enabled.

== "Dangerous mode" errors ==

=== 7012, "nosuchfunction" ===

This is triggered when $CFG->mnet_dispatcher_mode has been set to "dangerous", and the request is for something other than a file that ends in '.php', or the request comes from a client that isn't a trusted host

Development:MNet Errors

2010-01-11T03:57:30Z

Mjollnir: /* Authentication errors */

Development:MNet Errors

2010-01-11T03:41:32Z

Mjollnir:

Development:MNet Errors

2010-01-11T03:25:54Z

Mjollnir:

Development:MNet Errors

2010-01-11T03:13:02Z

Mjollnir:

Development:MNet Errors

2010-01-11T02:59:37Z

Mjollnir: /* Authentication errors */

Development:MNet Errors

2010-01-11T02:57:23Z

Mjollnir: /* Dispatch errors */

Development:MNet Errors

2010-01-11T02:53:35Z

Mjollnir: /* System errors */

Development:MNet Errors

2010-01-11T02:26:05Z

Mjollnir: /* Introduction */

Development:MNet Errors

2010-01-11T02:25:24Z

Mjollnir: New page: == Introduction == This wiki page attempts to document all the MNET error codes, what they mean, where they're called from, and what cases can trigger them. As MNET is theoretically plu...

Development:State of MNET

2010-01-06T03:29:21Z

Mjollnir: New page: == Introduction == The purpose of this wiki page is to capture the current state of the Moodle Networking feature as it stands coming up to the 2.0 release, the open bugs and problems, an...

== Introduction ==

The purpose of this wiki page is to capture the current state of the Moodle Networking feature as it stands coming up to the 2.0 release, the open bugs and problems, and come up with a plan to improve things for the 2.0 release, as well as fix some outstanding problems in 1.9

== Design flaws ==

== Coding style problems ==

== Security problems ==

Development:Scheduled Tasks Proposal

2010-01-05T22:36:52Z

Mjollnir: /* TODO */

{{Moodle 2.0}}

== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* '''Subtask''' an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* '''Moodle cron instance''' a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

The existing events API seems like it should provide a way to schedule tasks to be run outside of a user's request cycle, but in reality this just adds to the existing cron problem. We need to have a way in Moodle to schedule once off tasks to be run "at the next available time" which are picked up by cron. This can be used to process the event queue, but also for some code to just register a new once off cron event "on the fly" and be picked up on the next run.

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks
* An easy way for core and module code to schedule a once off task to be run as soon as possible

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

The unix crontab manpage goes on to say that one can use 3 letter words in the month and dayofweek fields (eg Sun or Feb). I don't think this is necessary for our implementation.

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|minute
|varchar(25)
|
|-
|hour
|varchar(25)
|
|-
|day
|varchar(25)
|
|-
|month
|varchar(25)
|
|-
|dayofweek
|varchar(25)
|
|-
|customised
|integer(1)
|0 or 1 - whether this time differs from what is in code
|}

This table is for all the normal scheduled regular tasks. The time fields are intially populated when a plugin is installed or upgraded, but can be overridden by an administrator, which sets the "customised" flag to 1. If the administrator later decides to revert their customisation, the original code-values are repopulated into this table.

'''scheduled_onceoff_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|nextruntime
|int(10)
|unix timestamp
|-
|customdata
|text
|any data or serialised information
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|}

This table is for the once off tasks, which are run and then deleted. There isn't a unique constraint on 'callfunction' in this table, because the same once off task may be scheduled twice before the first one is processed. In this case, the named lock will be obtained using a combination of callfunction and the id.

The original database specification had extra custom fields in the main scheduled_tasks table, that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. It is certain that we need it for the once off tasks, however, but in this case I think it's better to just have a text field that can either contain a single value, or a serialised blob of information.

The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some jobs block all others, rather than prioritising individual tasks. '''This decision may be later reverted''' especially for once off tasks, where some may be really urgent.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* It might be nice at some point to find a way to allow different subtasks to run on different servers by designation. This could be eventually added in to the administration screens as an extra setting (IP address)
* We obviously need some way to avoid different tasks trampling on eachother. We ran through a number of ideas already, from differentiating between read/write operations, to having dependencies or conflicts between tasks, to having each task say which database tables it uses. Finally we decided it would be best to just have some tasks that are able to simply block all others from being run. Anything to do with authentication and enrolment must block other tasks from running, as otherwise there could be the problem of for example, forum posts being emailed out just before someone is unenrolled from a course.
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then. This means that there also needs to be some global lastcronruntime flag somewhere (like in the config table)

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Write code to capture requests to schedule once off tasks
* Update portfolio code to use once off tasks rather than events API
* Evaluate integration of event API to once off tasks
* Test thoroughly

== TODO ==

Development:Scheduled Tasks Proposal

2010-01-05T22:33:36Z

Mjollnir: /* Tasks */

Development:Scheduled Tasks Proposal

2010-01-05T22:29:46Z

Mjollnir: /* Database */

{{Moodle 2.0}}

== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* '''Subtask''' an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* '''Moodle cron instance''' a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

The existing events API seems like it should provide a way to schedule tasks to be run outside of a user's request cycle, but in reality this just adds to the existing cron problem. We need to have a way in Moodle to schedule once off tasks to be run "at the next available time" which are picked up by cron. This can be used to process the event queue, but also for some code to just register a new once off cron event "on the fly" and be picked up on the next run.

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks
* An easy way for core and module code to schedule a once off task to be run as soon as possible

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

The unix crontab manpage goes on to say that one can use 3 letter words in the month and dayofweek fields (eg Sun or Feb). I don't think this is necessary for our implementation.

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|minute
|varchar(25)
|
|-
|hour
|varchar(25)
|
|-
|day
|varchar(25)
|
|-
|month
|varchar(25)
|
|-
|dayofweek
|varchar(25)
|
|-
|customised
|integer(1)
|0 or 1 - whether this time differs from what is in code
|}

This table is for all the normal scheduled regular tasks. The time fields are intially populated when a plugin is installed or upgraded, but can be overridden by an administrator, which sets the "customised" flag to 1. If the administrator later decides to revert their customisation, the original code-values are repopulated into this table.

'''scheduled_onceoff_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|nextruntime
|int(10)
|unix timestamp
|-
|customdata
|text
|any data or serialised information
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|}

This table is for the once off tasks, which are run and then deleted. There isn't a unique constraint on 'callfunction' in this table, because the same once off task may be scheduled twice before the first one is processed. In this case, the named lock will be obtained using a combination of callfunction and the id.

The original database specification had extra custom fields in the main scheduled_tasks table, that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. It is certain that we need it for the once off tasks, however, but in this case I think it's better to just have a text field that can either contain a single value, or a serialised blob of information.

The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some jobs block all others, rather than prioritising individual tasks. '''This decision may be later reverted''' especially for once off tasks, where some may be really urgent.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* It might be nice at some point to find a way to allow different subtasks to run on different servers by designation. This could be eventually added in to the administration screens as an extra setting (IP address)
* We obviously need some way to avoid different tasks trampling on eachother. We ran through a number of ideas already, from differentiating between read/write operations, to having dependencies or conflicts between tasks, to having each task say which database tables it uses. Finally we decided it would be best to just have some tasks that are able to simply block all others from being run. Anything to do with authentication and enrolment must block other tasks from running, as otherwise there could be the problem of for example, forum posts being emailed out just before someone is unenrolled from a course.
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then. This means that there also needs to be some global lastcronruntime flag somewhere (like in the config table)

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

== TODO ==

* This doesn't include a way to schedule new immediate tasks yet (something like scheduled_tasks_asap table)

Development:Scheduled Tasks Proposal

2010-01-05T21:33:30Z

Mjollnir:

{{Moodle 2.0}}

== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* '''Subtask''' an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* '''Moodle cron instance''' a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

The existing events API seems like it should provide a way to schedule tasks to be run outside of a user's request cycle, but in reality this just adds to the existing cron problem. We need to have a way in Moodle to schedule once off tasks to be run "at the next available time" which are picked up by cron. This can be used to process the event queue, but also for some code to just register a new once off cron event "on the fly" and be picked up on the next run.

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks
* An easy way for core and module code to schedule a once off task to be run as soon as possible

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

The unix crontab manpage goes on to say that one can use 3 letter words in the month and dayofweek fields (eg Sun or Feb). I don't think this is necessary for our implementation.

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|defaultminute
|varchar(25)
|
|-
|defaulthour
|varchar(25)
|
|-
|defaultday
|varchar(25)
|
|-
|defaultmonth
|varchar(25)
|
|-
|defaultdayofweek
|varchar(25)
|
|-
|adminminute
|varchar(25)
|
|-
|adminhour
|varchar(25)
|
|-
|adminday
|varchar(25)
|
|-
|adminmonth
|varchar(25)
|
|-
|admindayofweek
|varchar(25)
|
|-
|}

The difference between "admin" and "default" fields is that the default ones are what the code says when it registers the cronjobs, and the admin ones are the values that have been overridden by site administrators. It may be cleaner to do this in a separate table and use a left join.

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them.

The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* It might be nice at some point to find a way to allow different subtasks to run on different servers by designation. This could be eventually added in to the administration screens as an extra setting (IP address)
* We obviously need some way to avoid different tasks trampling on eachother. We ran through a number of ideas already, from differentiating between read/write operations, to having dependencies or conflicts between tasks, to having each task say which database tables it uses. Finally we decided it would be best to just have some tasks that are able to simply block all others from being run. Anything to do with authentication and enrolment must block other tasks from running, as otherwise there could be the problem of for example, forum posts being emailed out just before someone is unenrolled from a course.
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then. This means that there also needs to be some global lastcronruntime flag somewhere (like in the config table)

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

== TODO ==

* This doesn't include a way to schedule new immediate tasks yet (something like scheduled_tasks_asap table)

Development:Scheduled Tasks Proposal

2010-01-05T20:51:30Z

Mjollnir: /* Terminology */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* '''Subtask''' an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* '''Moodle cron instance''' a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|defaultminute
|varchar(25)
|
|-
|defaulthour
|varchar(25)
|
|-
|defaultday
|varchar(25)
|
|-
|defaultmonth
|varchar(25)
|
|-
|defaultdayofweek
|varchar(25)
|
|-
|adminminute
|varchar(25)
|
|-
|adminhour
|varchar(25)
|
|-
|adminday
|varchar(25)
|
|-
|adminmonth
|varchar(25)
|
|-
|admindayofweek
|varchar(25)
|
|-
|}

The difference between "admin" and "default" fields is that the default ones are what the code says, and the admin ones are the values that have been overridden by site administrators. It may be cleaner to do this in a separate table and use a left join.

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

== TODO ==

* This doesn't include a way to schedule new immediate tasks yet (something like scheduled_tasks_asap table)

Development:Scheduled Tasks Proposal

2010-01-05T05:41:24Z

Mjollnir:

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|defaultminute
|varchar(25)
|
|-
|defaulthour
|varchar(25)
|
|-
|defaultday
|varchar(25)
|
|-
|defaultmonth
|varchar(25)
|
|-
|defaultdayofweek
|varchar(25)
|
|-
|adminminute
|varchar(25)
|
|-
|adminhour
|varchar(25)
|
|-
|adminday
|varchar(25)
|
|-
|adminmonth
|varchar(25)
|
|-
|admindayofweek
|varchar(25)
|
|-
|}

The difference between "admin" and "default" fields is that the default ones are what the code says, and the admin ones are the values that have been overridden by site administrators. It may be cleaner to do this in a separate table and use a left join.

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

== TODO ==

* This doesn't include a way to schedule new immediate tasks yet (something like scheduled_tasks_asap table)

Development:Scheduled Tasks Proposal

2010-01-05T05:28:54Z

Mjollnir: /* Database */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|defaultminute
|varchar(25)
|
|-
|defaulthour
|varchar(25)
|
|-
|defaultday
|varchar(25)
|
|-
|defaultmonth
|varchar(25)
|
|-
|defaultdayofweek
|varchar(25)
|
|-
|adminminute
|varchar(25)
|
|-
|adminhour
|varchar(25)
|
|-
|adminday
|varchar(25)
|
|-
|adminmonth
|varchar(25)
|
|-
|admindayofweek
|varchar(25)
|
|-
|}

The difference between "admin" and "default" fields is that the default ones are what the code says, and the admin ones are the values that have been overridden by site administrators. It may be cleaner to do this in a separate table and use a left join.

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

Development:Scheduled Tasks Proposal

2010-01-05T05:27:19Z

Mjollnir: /* Database */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|-
|defaultminute
|varchar(25)
|
|-
|defaulthour
|varchar(25)
|
|-
|defaultday
|varchar(25)
|
|-
|defaultmonth
|varchar(25)
|
|-
|defaultdayofweek
|varchar(25)
|
|-
|adminminute
|varchar(25)
|
|-
|adminhour
|varchar(25)
|
|-
|adminday
|varchar(25)
|
|-
|adminmonth
|varchar(25)
|
|-
|admindayofweek
|varchar(25)
|
|-
|}

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

Development:Scheduled Tasks Proposal

2010-01-05T05:24:44Z

Mjollnir: /* Tasks */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|}

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Write screens to allow administrators to reschedule tasks
* Write code to transfer between unix-cron-syntax and user-friendly syntax (and vice versa)
* Test thoroughly

Development:Scheduled Tasks Proposal

2010-01-05T05:22:37Z

Mjollnir: /* Tasks */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|}

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cron process
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Test thoroughly

Development:Scheduled Tasks Proposal

2010-01-05T05:16:45Z

Mjollnir: /* Approach */

{{Moodle 2.0}}== Introduction ==

This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.

== Terminology ==

* *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
* *Moodle cron instance* a cron.php process

== Rationale ==

The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.

Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel

Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.

== Goals ==

* Centralised locking for '''all''' tasks
* A way consistent for '''all plugin types''' to register with Moodle (at installation/upgrade) when they want their jobs run
* More sophisticated scheduling rather than just intervals in seconds (eg every sunday at 11pm or similar) based on unix cron
* An administration screen in Moodle to allow site administrators to adjust the scheduling of individual tasks

== Approach ==

=== Plugin cron registration ===

Each plugin will be able to provide a db/tasks.php (alongside access.php and events.php etc) that lists all the cronjobs that it wants to have run. This will look something like the following:

<code php>
<?php
$tasks = array(
array(
'function' => 'yourmodule_cron_somedescription',
'minute' => '*',
'hour' => '*',
'day' => '*',
'month' => '*',
'dayofweek' => '*',
'description' => 'langstringkey', // this must correspond to get_string('langstringkey', 'yourmodule');
),
);

</code>

The fields are the same as normal unix cron, with the exception that you cannot use 3 letter words for the month and day of week fields like you can for unix cron. The following is straight from the unix manpage about cron:

<pre>

field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for ``first-last''.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen.
The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies
execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas.
Examples: ``1,2,5,9'', ``0-4,8-12''.

Step values can be used in conjunction with ranges. Following a range with ``/<number>''
specifies skips of the number's value through the range. For example,
``0-23/2'' can be used in the hours field to specify command execution every other hour
(the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps
are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

</pre>

=== Database ===

'''scheduled_tasks:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugintype
|varchar(50)
|plugintype - should match the path-style declarations in get_plugin_types (eg question/type, not qtype). Will be null for core tasks.
|-
|pluginname
|varchar(50)
|name of the plugin. Will be null for core tasks.
|-
|callfunction
|varchar(200) (unique)
|the function to call. Must be unique, as it will be used for the locking.
|-
|lastruntime
|int(10)
|unix timestamp
|-
|nextruntime
|int(10)
|unix timestamp
|-
|blocking
|int(1)
|0 or 1 - whether this task, when running, blocks everything else from running.
|}

The original database specification had extra custom fields that the cronjobs could insert information into, called custom1 and custom2 and so on. I've removed these from this specification until such time as we have a solid use-case for them. The original spec also had a priority field, but this has been removed after the conversation in Jizerka, which led to the proposal to just let some core jobs block all others, rather than prioritising individual tasks.

=== Locking ===

Penny and Tim originally thought that the best approach was to try and do something that would cause an exception to be thrown - for example, try to insert into a row that had a unique constraint on it, and catch the exception. However, this will cause far too much noise in the logs. Matt Oquist came up with a different approach in MDL-21110. We could potentially change this slightly to allow alternative implementations, by means of an abstract class and factory method (this was suggested by Sam Marshall), but probaby isn't needed for the initial implementation.

=== Black magic ===

Cron.php will need to be rewritten to look something like this:

<code php>
<?php

while ($nexttask = cron_get_next_task()) {
cron_call_function($nexttask);
}

</code>

With some black magic to hand out the next task, which does:

* Checks how long the existing process is allowed to run for
* Figures out if there's already a "blocking" task running
* Figures out the next task that's scheduled
* Tries to get a lock on it
* Returns that task

== Unresolved issues/ideas ==

* Do we need to allow for scheduling different subtasks on different servers?
* We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
* We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
* When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.

== Psuedo code proposal ==
Moved [[Development_talk:Scheduled_Tasks_Proposal|to the talk page]]

== Audit of current cron ==

{| class="nicetable"
|-
! Main section
! Subtask
! Frequency
! Notes
|-
| session_gc
|
| every run
|
|-
|mod/assignment
|plugins (none)
|every minute
|
|-
|mod/assignment
|message submissions
|every minute
|checks last run time
|-
|mod/chat
|update chat times
|every five minutes
|
|-
|mod/chat
|update_events
|every five minutes
|
|-
|mod/chat
|delete old chat_users and add quits
|every five minutes
|
|-
|mod/chat
|delete old messages
|every five minutes
|
|-
|mod/data
|
|every minute
|no _cron function (includes file unnecessarily)
|-
|mod/forum
|mail posts
|every minute
|checks last run time
|-
|mod/forum
|digest processing
|every minute
|
|-
|mod/forum
|delete old read tracking
|every minute
|
|-
|mod/scorm
|reparse all scorms
|every five minutes
|does hourly checking
|-
|mod/wiki
|delete expired locks
|every hour
|-
|blocks/rss_client
|update feeds
|every five minutes
|
|-
|quiz/report/statistics
|delete old statistics
|every run
|
|-
|admin/reports
|none
|every run
|
|-
|language_cache

|every run
|
|-
|remove expired enrolments
|
|every run
|
|-
|main gradebook
|lock pending grades (*2)
|every run
|
|-
|main gradebook
|clean old grade history
|every run
|has a TODO to not process as often
|-
|event queue
|
|every run
|potentially large
|-
|portfolio cron
|clean expired exports
|every run
|potentially large
|-
|longtimenosee

|20%
|
|-
|deleteunconfirmedusers
|
|20%
|
|-
|deleteincompleteusers
|
|20%
|
|-
|deleteoldlogs
|
|20%
|
|-
|deletefiltercache
|
|20%
|
|-
|notifyloginfailures
|
|20%
|
|-
|metacourse syncing
|
|20%
|
|-
|createpasswordemails
|
|20%
|
|-
|tag cron
|
|20%
|
|-
|clean contexts
|
|20%
|
|-
|gc_cache_flags
|
|20%
|
|-
|build_context_path
|
|20%
|
|-
|scheduled backups
|
|daily (admin defined)
|
|-
|make rss feeds
|
|every run
|
|-
|auth/mnet
|keepalives
|every run
|
|-
|auth/mnet
|delete old sessions
|every run
|
|-
|auth/ldap
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/cas
|sync users
|custom
|not scheduled (external cronjob)
|-
|auth/db
|sync users
|custom
|not scheduled (external cronjob)
|-
|enrol/authorize
|clears old data
|daily (admin defined)
|
|-
|enrol/authorize
|notifies administrators of old data
|daily (admin defined)
|
|-
|enrol/authorize
|process orders & email teachers
|every run
|
|-
|enrol/flatfile
|read file and sync users
|every run
|!?!
|-
|enrol/imsenterprise
|read file and sync users
|every run
|!?!?!
|-
|enrol/manual
|notify people of pending unenrolments
|daily
|
|-
|statistics
|
|daily (admin defined)
|huge
|-
|grade/import
|none
|every run
|
|-
|grade/export
|none
|every run
|
|-
|grade/reports
|none
|every run
|
|-
|fetch blog entries
|
|every run
|
|-
|file gc
|
|(optional) daily, else every run?
|
|-
|local cron
|
|
|
|}

== Tasks ==

* Audit all existing cronjobs (done)
* Implement the locking code, either Matt's or something similar and write robust tests for it (this will be hard to test perhaps - can we test race conditions using simpletest?)
* Write the black magic that hands out the next task to be run for a given cronjob
* Rewrite cron.php to use the black magic
* Migrate all the existing cronjobs to the new system
* Test thoroughly

Development:Scheduled Tasks Proposal

2010-01-05T05:06:32Z

Mjollnir: /* Tasks */

Development:Scheduled Tasks Proposal

2010-01-05T04:48:21Z

Mjollnir: /* Psuedo code proposal */

Development:Scheduled Tasks Proposal

2010-01-05T04:42:57Z

Mjollnir: /* Goals */

Development:Scheduled Tasks Proposal

2010-01-05T04:39:14Z

Mjollnir: /* Approach */

Development:Scheduled Tasks Proposal

2010-01-05T04:24:05Z

Mjollnir: /* Database */