Leonel:
Muchas gracias por la asistencia. Tal como señalaba Ricardo, subir max_input_vars a esos valores hace que el sistema sea “hackeable”.
Aca te hacemos una consulta: en la prueba anterior tomo una hora matricular 1000 alumnos. Tenemos materias donde tenemos 16.000 mas o menos. ¿Cómo hacemos con la ventana del navegador ? ¿Podemos tirar la matriculación y cerrarla o hay que dejarla abierta por 15/16hs?
Muchas gracias!
Saludos,
Federico
Agregamos una consulta:
Considerando que una de las asignaturas tiene alrededor de 24.000 inscripciones, ¿a qué valores correspondería elevar los parámetros que venimos conversando?
Actualmente se encuentran en:
max_input_vars = 10000
post_max_size = 900M
¿Tenemos que modificar adicionalmente alguna otra cosa? (Timouts, pensamos, por ejemplo)
Gracias!
Federico
Hola
Con respecto al timeout, lo pueden subir el tiempo necesario! tengan en cuenta este post del foro
Saludos
Hola Federico, te respondo:
Muchas gracias por la asistencia. Tal como señalaba Ricardo, subir max_input_vars a esos valores hace que el sistema sea "hackeable".
Acá lo que se puede hacer es setearlo en tiempo de ejecución solo en la función que se necesita, ej:
Función crearUsuarios de la clase php/nucleo/moodle/moodle_nucleo.php:
public function crearUsuarios($usuarios, $excepciones = false)
{
ini_set('max_input_vars', 'xxxxx');
ini_set('post_max_size', 'xxxxx');
ini_set('max_execution_time', '0');
............
try {
$response = $this->clienteGuzzle->post('', [
'form_params' => [
'wstoken' => $this->token,
'moodlewsrestformat' => static::FORMATO_RESPUESTA_JSON,
'wsfunction' => 'core_user_create_users',
'users' => array_a_utf8($usuarios)
]
]);
ini_restore('max_input_vars');
ini_restore('post_max_size');
ini_restore('max_execution_time');
............
}
Referencias: ini_set e ini_restore.
Acá te hacemos una consulta: en la prueba anterior tomo una hora matricular 1000 alumnos. Tenemos materias donde tenemos 16.000 mas o menos. ¿Cómo hacemos con la ventana del navegador ? ¿Podemos tirar la matriculación y cerrarla o hay que dejarla abierta por 15/16hs?
Acá tendrías que configurar las variables: max_execution_time a 0, max_input_time a 0 y el timeout de Apache.
saludos.
2
Estos parametros que les pasamos son los del apache del Moodle, y por lo que pude ver el cambio en la funcion crearusuarios seria en Guarani; es esto correcto?
Saludos,
Valeria
Hola Valeria,
Las variables max_input_vars y post_max_size se configuran en el servidor de Moodle. Osea, el ejemplo de código que les pase anteriormente no iría en Guaraní.
Las variables de “timeout” en Guaraní, max_execution_time y en Apache también.
saludos.
2
Leonel:
Bien, realizamos todo lo que nos indicaron e intentamos nuevamente realizar la matriculación. Retomamos la comisión que veníamos trabajando (en la que se estaban matriculando de a 100 los alumnos en el curso virtual a través del proceso en Guaraní) pero devolvió error por mails duplicados. Verificamos la base de Personas en Guaraní y no se encuentra ningún mail duplicado allí, y en Moodle los usuarios que figuran fueron creados a través del proceso Guaraní, por lo que deberían estar vinculados. Adjuntamos el log de Moodle al momento de intentar esta matriculación.
Luego intentamos vincular un curso nuevo, pero cuando intentamos vincular al docente con su usuario Moodle (Administrar Personas > Solapa Moodle), el buscador de personas no nos devuelve ningún resultado. Sin embargo, los alumnos matriculados anteriormente y el docente del curso anterior sí se mantienen vinculados. Verificamos la conexión con Moodle y está correcta. En este caso, el log Guaraní devolvió lo siguiente (igual adjuntamos el log completo, por las dudas):
[DEBUG][guarani] base_uri: https://campusubaxxi35lab.rec.uba.ar/webservice/rest/server.php^M
[DEBUG][guarani] Token: d2f7b248e768a36a00ae844b468d300e^M
[DEBUG][guarani] Response:^M
[DEBUG][guarani] array (
'exception' => 'invalid_response_exception',
'errorcode' => 'invalidresponse',
'message' => 'Detectado valor de respuesta no válido',
)^M
[DEBUG][guarani] SQL con perfil de datos: SELECT plataforma,
persona,
id_usuario_externo
FROM int_pv_usuarios
WHERE plataforma = '1'
;^M
[DEBUG][guarani] Filtrado combo_editable 'id_usuario_externo', Respuesta: array (
)
Utilizamos el mismo docente que en el primer curso que testeamos para realizar la vinculación con esta nueva materia, para probar otro conjunto de personas. Intentamos la matriculación en Moodle y luego de un par de horas tuvimos el mismo resultado. En este caso, el log de Apache presentó el siguiente error:
[Tue Apr 07 21:39:53.343934 2020] [:error] [pid 9575] [client 10.5.14.189:42124] Potential coding error - active database transaction detected during request shutdown:\n* line 155 of /user/externallib.php: call to moodle_database->start_delegated_transaction()\n* line 1426 of /webservice/lib.php: call to core_user_external::create_users()\n* line 1290 of /webservice/lib.php: call to webservice_base_server->execute()\n* line 44 of /webservice/rest/server.php: call to webservice_base_server->run()\n
No logramos encontrar el origen del error de mails duplicados en esta ocasión, así como tampoco entendemos por qué el buscador de usuarios Moodle de Administrar Personas no trae ningún resultado (anteriormente utilizamos este mismo medio para vincular al docente del primer testeo).
Agradecemos toda la ayuda que nos puedan dar!
Muchas gracias!
Federico
fallo.txt (349 KB)
20200407 Tabla campusubaxxi.mdl_logstore_standard_log.zip (498 KB)
Adjunto el log de la última corrida. Me llama la atención:
[INFO][toba] componente(37000315): [ evento ] El METODO [ evt__cambiar_tab_pant_educacion_virtual ] no existe - ‘cambiar_tab_pant_educacion_virtual’ no fue atrapado^M
[DEBUG][guarani] SQL con perfil de datos: SELECT count(sga_comisiones.comision) as cant
FROM sga_comisiones
WHERE sga_comisiones.elemento = ‘67’ AND
sga_comisiones.periodo_lectivo = ‘4’ AND
sga_comisiones.ubicacion = ‘23’ AND
trim(regexp_replace(translate(sga_comisiones.nombre,‘ÀÁÂÃÄÅàáâãäåÒÓÔÕÖØòóôõöøÈÉÊËèéêëÌÍÎÏìíîïÙÚÛÜùúûüÿ’,‘AAAAAAaaaaaaOOOOOOooooooEEEEeeeeIIIIiiiiUUUUuuuuy’), ‘{2,}’, ’ ',‘g’)) ILIKE ‘Sede Central UBA XXI (CABA)’
AND sga_comisiones.comision <> ‘2’ ;^M
[WARNING][guarani] componente(37000342): guarani_pers_datos_tabla El registro tiene una estructura incorrecta: El campo ‘requerido’ no forma parte de la DEFINICION.^M
… 150 filas iguales
2147 [DEBUG][guarani] SQL con perfil de datos: SELECT DISTINCT responsable_academica^M
2148 FROM sga_propuestas_ra^M
2149 WHERE sga_propuestas_ra.propuesta IN (68,1,10,59,65,60,11,12,13,14,15,58,96,64,57,56,50,49,48,47,46,45,44,43,42,41,55,40,89,75,63,2,21,22,23,74,54,25,87,86,84,85,99,53,39, 4,38,27,37,36,83,16,97,26,73,72,35,28,80,82,81,79,78,77,91,76,94,52,51,71,24,66,98,69)^M
2150 [DEBUG][guarani] SQL con perfil de datos: SELECT
2151 par_parametros_sistema.parametro,
corrida-1930.zip (66.6 KB)
Hola, antes que nada gracias por los logs!!!
Les recomiendo que hagan el paso 8 de esta documentación, para que Moodle muestra información de debug en las respuestas de los WS.
Lo que veo que les esta ocurriendo es que el campo username del usuario de Moodle tiene caracteres en mayúscula, esto hace que se rompa la respuesta de WS core_user_get_users. Por favor, asegúrense de que todos los usuarios de Moodle tengan el campo username en minúscula, y luego vuelvan a probar el caso.
saludos.
2
Leonel:
Realizamos las modificaciones recomendadas y logramos reparar el buscador de usuarios de Moodle en Guaraní modificando los usernames a minúsculas. Por ese lado, todo OK.
Luego intentamos una matriculación en Moodle de una materia de 5.000 inscriptos y corrió perfectamente. No obstante, luego intentamos la matriculación de otra materia, de 12.000 inscriptos, y el proceso estuvo corriendo alrededor de 20 hs sin respuesta. Según informaron desde sistemas, Moodle no estaba realizando transacciones.
Reiniciaron el sistema y volvimos a correr esa matriculación masiva. En esta ocasión nos devolvió el mensaje de error de mails duplicados nuevamente (estamos verificando el log debug para identificar cuál es el caso). Los logs además incluyeron esta siguiente información:
[Fri Apr 10 07:54:19.839288 2020] [:error] [pid 28550] [client 10.5.14.189:50802] PHP Fatal error: Maximum execution time of 360 seconds exceeded in /var/www/campusubaxxi/moodle/lib/moodlelib.php on line 4614
[Fri Apr 10 07:54:19.841941 2020] [:error] [pid 28550] [client 10.5.14.189:50802] Potential coding error - active database transaction detected during request shutdown:\n* line 155 of /user/externallib.php: call to moodle_database->start_delegated_transaction()\n* line 1426 of /webservice/lib.php: call to core_user_external::create_users()\n* line 1290 of /webservice/lib.php: call to webservice_base_server->execute()\n* line 44 of /webservice/rest/server.php: call to webservice_base_server->run()\n
[Fri Apr 10 07:54:22.772990 2020] [:error] [pid 22124] [client 10.5.14.189:51040] Debugging: This page should be using theme ubaxxi which cannot be initialised. Falling back to the site theme adaptable in \n* line 704 of /lib/outputlib.php: call to debugging()\n* line 1553 of /lib/pagelib.php: call to theme_config::load()\n* line 677 of /lib/pagelib.php: call to moodle_page->initialise_theme_and_output()\n* line 864 of /lib/pagelib.php: call to moodle_page->magic_get_theme()\n* line 345 of /lib/outputcomponents.php: call to moodle_page->get_renderer()\n* line 381 of /user/lib.php: call to user_picture->get_url()\n* line 662 of /enrol/externallib.php: call to user_get_user_details()\n* line 1426 of /webservice/lib.php: call to core_enrol_external::get_enrolled_users()\n* line 1290 of /webservice/lib.php: call to webservice_base_server->execute()\n* line 44 of /webservice/rest/server.php: call to webservice_base_server->run()\n
[Fri Apr 10 07:54:22.934686 2020] [:error] [pid 22124] [client 10.5.14.189:51040] Debugging: This page should be using theme ubaxxi which cannot be initialised. Falling back to the site theme adaptable in \n* line 704 of /lib/outputlib.php: call to debugging()\n* line 1553 of /lib/pagelib.php: call to theme_config::load()\n* line 677 of /lib/pagelib.php: call to moodle_page->initialise_theme_and_output()\n* line 864 of /lib/pagelib.php: call to moodle_page->magic_get_theme()\n* line 345 of /lib/outputcomponents.php: call to moodle_page->get_renderer()\n* line 381 of /user/lib.php: call to user_picture->get_url()\n* line 662 of /enrol/externallib.php: call to user_get_user_details()\n* line 1426 of /webservice/lib.php: call to core_enrol_external::get_enrolled_users()\n* line 1290 of /webservice/lib.php: call to webservice_base_server->execute()\n* line 44 of /webservice/rest/server.php: call to webservice_base_server->run()\n
¿Puede estar vinculado?
Muchas gracias!
Saludos,
Federico
Bueno:
Verificamos el log debug que indica que un usuario presenta mail duplicado. Sin embargo, no encontramos dicha duplicación en ninguno de los usuarios activos, ni en Guaraní y ni en Moodle. El error que dispara el log es el siguiente:
[DEBUG][guarani] Response:^M
[DEBUG][guarani] array (
'exception' => 'dml_write_exception',
'errorcode' => 'dmlwriteexception',
'message' => 'Error al escribir a la base de datos',
'debuginfo' => 'Lock wait timeout exceeded; try restarting transaction
INSERT INTO mdl_user (username,firstname,lastname,email,auth,idnumber,lang,calendartype,timezone,country,confirmed,mnethostid,password,maildisplay,mailformat,maildigest,autosubscribe,trackforums,timecreated,timemodified) VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
[array (
0 => \'******\',
1 => \'Gonzalo Agustin\',
2 => \'******\',
3 => \'*****@gmail.com\',
4 => \'manual\',
5 => \'67889\',
6 => \'es\',
7 => \'gregorian\',
8 => \'America/Argentina/Buenos_Aires\',
9 => \'AR\',
10 => 1,
11 => \'1\',
12 => \'\',
13 => \'0\',
14 => \'1\',
15 => \'1\',
16 => \'1\',
17 => \'0\',
18 => 1586510407,
19 => 1586510407,
)]',
)^M
[DEBUG][toba] Mensaje a usuario: Falló la actualización de alumnos en Moodle. <b>Posibles Causas:</b> Alumnos con el mismo email asignado.^M
(Debido a que presenta datos sensibles, reemplazamos **** en los campos de usuario, apellido y mail).
Saludos,
Federico
Hola Federico
Por lo que vemos en el log, hay un proceso colgado en el motor de base de datos de Moodle
'debuginfo' => 'Lock wait timeout exceeded; try restarting transaction....
¿Intentaron desbloquar ese proceso? y ¿aumentar los tiempos de bloqueo?
Encontramos este post googleando! (¿utilizan mysql en moodle ?)
Saludos
6
Hola, agrego a lo de Sergio:
En la versión 3.17 cada vez que falla la “Actualización de alumnos”, en el mensaje de error pone por defecto “posibles causas: Emails duplicados”, pero el error verdadero se encuentra en los logs. A partir de las 3.18 ya se muestra el error devuelto por Moodle en dicho mensaje.
Lock wait timeout exceeded; try restarting transactionComo dice Sergio, al ejecutar la query que inserta los usuarios en Moodle (tabla [b]mdl_user[/b]), se corre en el marco de una transacción, y como son tantos hace timeout. Quizás estos posts ayuden: https://dba.stackexchange.com/questions/100984/mysql-lock-wait-timeout-exceeded-try-restarting-transaction (propone aumentar la variable [b]innodb_lock_wait_timeout[/b] de MYSQL). https://www.javierrguez.com/mysql-error-lock-wait-timeout-exceeded/ (este esta en español)
saludos.
2
Hola,
Hice la búsqueda “mysql innodb_lock_wait_timeout unlimited”, pero por lo que vi no se pude configurar para que no tenga limites (infinito tiempo de espera).
Quizás averiguando un poco mas pueden encontrar como se hace, o sino deberán ponerle un valor alto.
Saludos.
2