Closed sgelabert-dgtic closed 6 years ago
Además, también se incluirán los siguientes requisitos:
Se ha comiteado ya todos los cambios, hay que tener en cuenta:
La sql a ejecutar está en el script gusite_update_schema_from_1.4.1_to_1.4.2.sql
ALTER TABLE GUS_SOLJOB MOVE LOB(JOB_DESCRI) STORE AS GUS_SOLJOB_JOB_DESCRI_LOB (TABLESPACE GUSITE_LOB INDEX GUS_SOLJOB_JOB_DESCRI_LOB_I);
Se añadió también el index GUS_SOLJOB_JOB_DESCRI_LOB_I rcomo se comenta en el documento de estandares de BBDD ( https://www.caib.es/sites/dgtic/es/estandards_de_desenvolupament-7621/ ).
es.caib.gusite.maxjob.solr = 10
es.caib.gusite.maxclob.solr = 100
La primera indica el nº máximo de jobs que debe haber en la base de datos (se puede ejecutar manualmente la limpieza en el botón 'netejar tasques' o bien automáticamente está dentro de la tarea periódica). De esta manera, evitamos tener un tamaño excesivo en la tabla.
La segunda propiedad indica el tamaño de la información a almacenar. Se indica en MB, si queremos por ejemplo 1 KB habría que poner '0.0009765625' (1M / 1024).
Por defecto, si no se introducen los valores en el jboss-service, el tamaño máximo del CLOB son 100 MB y 10 las tareas en BBDD.
ALTER TABLE GUS_SOLJOB MOVE LOB(JOB_DESCRI) STORE AS GUS_SOLJOB_DESCRI_LOB (TABLESPACE GUSITE_LOB);
Actualizado el alter table para que que no incluye el index. Hemos añadido también el resto de tablas (aun así, se recomienda ejecutar primero la sentencia asociada a GUS_SOLJOB). Respecto al problema del tamaño (posible de 50 GB), no debería de producirse debido a la limpieza de jobs en la tarea periódica (por defecto, a 10 ejecuciones en la tabla).
La indexació completa ha finalitzat sobre l'entorn de PREproducció. He sol·licitat al DBA que m'indiqui el creixament del tablespace de lobs després de la indexació (prèviament haviem fet un delete de la taula GUS_SOLJOB). Dubtes:
Indexats 205 (27%) microsites.
amb el resultat de la select. Es comprova la visibilitat de la UA associada al microsite?
Buenas, debería indicar el número de microsites que lleva indexados 205 (aproximadamente el 27% de un total de 744 microsites), es decir, aun debe estar indexándose.
Mientras se está ejecutando, se almacena cuantos microsites lleva para hacerse una idea por el estado de indexación que lleva. ¿Sale marcado con la fecha final?
Lo actualizaremos con los siguientes cambios:
Para ver la información de los problemas se podrá ver en el campo CLOB. Saludos!
Sí, el job s'ha marcat com a finalitzat, de fet s'han llançat tasques programades posteriors a la indexació total. Adjunt captura de pantalla. Log de la indexació entorn de PReproducció http://tn.caib.es/Tp0LTa6q
A més el DBA m'informa que la indexació ha generat uns 176MB sobre el tablespace de lob
Hemos comiteado todos los cambios que contienen una restructuración del código y mejoras en el log para mejorar la información del error.
Se debería volver a ejecutar un indexar todo en GUSITE y, tras terminar de ejecutar, pasarnos el documento que genera la indexación total y el log.
Es completa la indexació completa sobre l'entorn de PREproducció en 11h:30min. El tablespace de lob pel camp GUS_SOLJOB. JOB_DESCRI ocupa 200MB S'envia per correu log de a indexació total on s'oberven 82 microsites amb problemes d'indexació, d'un total de 704. Es sol·licita revisar el problemes d'indexació.
Revisamos el log y os avisamos con un resumen de los problemas encontrados.
Se han observado los siguientes tipos de errores:
Se ha observado algún error con las traducciones de algunas de las entidades porque no es capaz de indexar en algún idioma. Parece que principalmente se debe porque o no tiene traducciones o las traducciones están vacías o con algún problema que impide recuperarlas correctamente. Por ejemplo, el microsite 148:M148 (noticias con id 11877, 11878, 11882, 11876, 11879, 11880, 11884, 11885, 11886, 11844) . Ejecutar las siguientes consultas:
SQL Para ver el estado de las traducciones de las noticias 67661, 67663 y 67664
select *
from gus_notidi
where nid_notcod in (11877, 11878, 11882, 11876, 11879, 11880, 11884, 11885, 11886, 11844);
SQL para ver las noticias sin traducciones
select *
from gus_notics
where not_codi not in (select nid_notcod from gus_notidi);
Según el resultado de las consultas tomaremos una decisión pero, en caso de que no existen las traducciones, habrá que generar alguna traducción bien a través de la aplicación de manera manual o de manera directa en la bbdd para que se puedan indexar. El problema de las traducciones sólo se ha observado en las noticias.
Si una actividad de la agenda no tiene asignado un evento no se puede indexar, se ha comprobado, por ejemplo, con el microsite 5938:M170130123708547171055.
Ejecutar la SQL y, a las agendas que devuelva la consulta, asignarle una actividad si se desea que la actividad se indexe.
select *
from gus_agenda
where AGE_ACTIVI is not null;
Con Solr, parece que se genera un problema para indexar documentos porque se excede el tamaño de la petición POST, para evitar el problema debemos ampliar el tamaño modificando el fichero solrconfig.xml (situado en SOLR_CARPETA/server/solr/caib/solrconfig.xml ) cambiando la propiedad de formdataUploadLimitInKB="2048" a formdataUploadLimitInKB="4096".
Se realizará primero una prueba con el microsite 407:M09073009045028886048. Primero se indexará el microsite para comprobar el número de errores que tienen y posteriormente actualizaremos el fichero solrconfig.xml y volveremos a reindexar para ver su correcto funcionamiento.
Para parar solr --> solr stop -all Para arrancar solr --> solr start
Quedamos a la espera que nos confirméis el cambio del tamaño del upload en solr.
Cuando podáis, incluirnos el resultado de las consultas SQL indicadas en el comentario anterior.
Buenas, necesitamos que indexéis de nuevo el microsite M09073009045028886048 para observar el comportamiento con el aumento de la petición POST de SOLR.
He indexat el microsite M09073009045028886048 sobre l'entorn de PREproducció. Problemes:
Buenas, revisamos el problema del botón de veure informació.
Respecto al problema de la URI, el problema tiene que se debido a alguna restricción de tamaño sobre las peticiones a nivel del servidor de Solr. Hemos visto que el problema puede estar relacionado con la configuración en el jetty que lleva incrustrado Solr. Probad a aumentar el tamaño de este parámetro ubicado en el fichero SOLR_CARPETA\solr svn\server\etc\jetty.xml:
<Set name="requestHeaderSize"><Property name="solr.jetty.request.header.size" default="32768" /></Set>
Habría que reiniciar solr después de actualizar el fichero.
Acaben d'actualitzar la mida del header del jetty sobre l'entorn de PREproducció. Podem provar-ho amb la versió https://github.com/GovernIB/gusite/commit/b0fd4bf o ens hem d'actualitzar a la https://github.com/GovernIB/gusite/commit/1c6f42a55cde082ad653d56ce4c0ba7986506159 ?
Para probar el header no es necesario actualizar rolsac, sólo hay que reiniciar el servidor solr.
Adjunt resultats indexació microsite Microsite 407:M09073009045028886048 sobre l'entorn de PREproducció:
-Anem a desindexar el microsite arrel.
-Anem a indexar els components
** Arxius:
**** Total arxius 394 (Incorrectes:0)
** Enquestes:
**** Total enquestes 0 (Incorrectes:0)
** Faqs:
**** Total faqs 0 (Incorrectes:0)
** Noticies:
**** Total noticias 0 (Incorrectes:0)
** Agendas:
**** Total agenda 0 (Incorrectes:0)
** Continguts:
**** Total continguts 10 (Incorrectes:5)
No apareix més informació sobre els 5 continguts incorrectes.
Hemos actualizado el tratamiento de los casos en contenidoFacadeEJB que son erróneos y, en caso de error, hemos mejorado el tratamiento del error a través de ExceptionUtils. Se debería de volver a ejecutar la indexación del microsite M09073009045028886048 bien para que se resuelvan los errores o para que se muestre el error producido.
El botó per veure el log segueix sense funcionar. Adjunt captura de pantalla.
Adjunt log indexació del microsite M09073009045028886048 a partir del codi HTML de la pàgina. log_ M09073009045028886048.txt
Hemos actualizado para que el resultado de la acción de indexación se descargue.
Amb la versió https://github.com/GovernIB/gusite/commit/93b17ca he tornat a reindexar el microsite M09073009045028886048.
Microsite 407:M09073009045028886048
-Anem a desindexar el microsite arrel.
-Anem a indexar els components
** Arxius:
**** Total arxius 394 (Incorrectes:0)
** Enquestes:
**** Total enquestes 0 (Incorrectes:0)
** Faqs:
**** Total faqs 0 (Incorrectes:0)
** Noticies:
**** Total noticias 0 (Incorrectes:0)
** Agendas:
**** Total agenda 0 (Incorrectes:0)
** Continguts:
**** Total continguts 10 (Incorrectes:5)
He llançat també una indexació completa sobre l'entorn de PREproducció que encara no ha acabat. En tenir-ho us adjunt eles resultats
Adjunt resultats indexació completa per correu sobre l'entorn de PRE amb la versió https://github.com/GovernIB/gusite/commit/93b17ca. S'observen errors d'indexació però amb el log no sabem quins.
El prioritari és la correcció d'errors, la millora del log pot quedar per una segona versió.
buenas, hemos estado revisando y necesitariamos que se ejecute la siguiente consulta en PRE. ¿Nos podeis facilitar los resultados de la query en PRE?
select * from gus_micros where mic_version is null
Adjunt resultat de la consulta sobre l'entorn de PREproducció: export_gus_micros.xlsx
Estamos revisando el log y hemos revisado que se producen errores de URI too large, en el solr de preproducción se modificó jenkins con los parámetros para aumentar el tamaño?
Respecto a los 4 microsites que tienen valor nulo, entendemos que no deberían existir microsites con dicho valor versión a nulo, ¿introducimos el valor v1 y una restricción a no nulo en bbdd para evitar que existan más microsites con dicho valor a nulo?
En el CAI-1744260 de 22/09/2017 s'introduïren els següents canvis sobre el SOLRSOLR_CARPETA\solr svn\server\etc\jetty.xml
<Set name="requestHeaderSize"><Property name="solr.jetty.request.header.size" default="32768" /></Set>
Ok, als canvis de BBDD. Ho acab de consultar i no existeix cap microsite sense versió a la BBDD de PROducció.
La sql a ejecutar:
update gus_micros set mic_version = 'v1' where mic_version is null;
alter table gus_micros modify mic_version not null;
Además, se ha mejorado el tratamiento de la versión y de la extracción de errores por el log. Hemos actualizado el solrapi.jar (para el tratamiento de descripción de longitud excesiva para evitar el problema de la URI), los cambios están también comiteados en el svn de solrapi.
Se debería de generar el ear y volver a probar una indexación de todos los microsites aprovechando el jueves.
Hay un error en la nomenclatura de la version en los scripts de BBDD:
/scripts/bbdd/1.4/gusite_update_data_from_1.4.2_to_1.4.3.sql
/scripts/bbdd/1.4/gusite_update_schema_from_1.4.2_to_1.4.3.sql
Deberian pasar de la 1.4.1 a la 1.4.2
Hay que tener en cuenta que ya existen otros scripts de paso de la 1.4.1 a la 1.4.2, habría que ver si se pueden integrar en un solo DML i un DDL o si por dependencias hay que secuenciar de una determinada manera las operaciones.
Reordenado los scripts. Sólo se ha incluido en el DDL la declaración a no nulo del campo versión.
El problema de microsites con versiones a nulo sólo afectaba a preproducción por lo que en dicho entorno, si aun no se ha ejecutado, se tendría que ejecutar:
update gus_micros set mic_version = 'v1' where mic_version is null;
Respecto a la indexación, se debería volver a generar el ear y repetir la indexación para obtener el log con la ejecución.
Remet per correu resultats indexació completa de microsites sobre l'entorn de PRE. Segons el log la indexació completa va començar 13/10/2017 12:17 i va acabar 13/10/2017 22:57. A partir de les 12:54 comencen a apareixer errors de connexió amb la BBDD. Pot ser que hi hagi problemes de transaccions enganxades ? He sol·licitat que s'amplii el nombre de connexions contra la BBDD de PREproducció (ara són 50, les mateixes que a PROducció) i acab de llançar de nou la indexació completa.
Tras revisar el log de indexación hemos detectado las siguientes incidencias:
Parece ser que existen con el campo tipo acceso no nulo ¿Podéis verificar si esto es así en PRE y en PRO? Si existen valores nulos, entendemos que habría que hacer este campo no nulo y poner un valor por defecto para los nulos.
select *
from gus_micros
where MIC_TIPO_ACCESO is null;
El API de Rolsac no ha estado operativa durante un período de tiempo, no pudiéndose indexar (desde las 11:20 a las 11:52)
No hemos visto que se vuelva a producir el error de Request URI too long
Hemos detectado en el código que había un par de sitios dónde no sacábamos la información de la excepción. Hemos modificado el código para meter la traza y poder ver que está fallando.
Vemos que no se están normalizando los nombres de los ficheros al almacenarse en disco. Entendemos que la recuperación de estos ficheros debe funcionar correctamente ya que si no os habríais dado cuenta antes. De todas formas, pensamos que sería una buena práctica normalizar el nombre de los ficheros (evitar espacios, acentos, caracteres raros, etc.). Para confirmar que no es problema de recuperación de estos ficheros, hemos cogido del log unos cuantos ficheros de ejemplo para que nos confirméis que realmente no existen en disco: /app/caib/gusite/arxius/3888/122811/CÓDIGO DE BUENAS PRÃ�CTICAS COMPLETO.pdf /app/caib/gusite/arxius/3888/122813/BARÓMETRO 2008.pdf /app/caib/gusite/arxius/3888/122816/14-01 dos Subvenciones.pdf /app/caib/gusite/arxius/3888/122817/22-01 MEMORIA 2009 organs.pdf /app/caib/gusite/arxius/3888/122871/Model_Memòria.doc /app/caib/gusite/arxius/3888/122877/Sol·licitud.doc /app/caib/gusite/arxius/3888/122832/12-01 Enquesta de Salut 2007.pdf
Antes de volver a lanzar una indexación completa, nos gustaría hacer pruebas sobre un conjunto de microsites después de que subáis los cambios que hemos realizado. Primero deberíamos extraer un microsite de un contenido e indexarlo junto a los microsites comentados:
select mnu_miccod
from gus_menu
where mnu_codi in
(select con_mnucod
from gus_conten
where con_codi = 26347 );
Los microsites a indexar serían: 264, 282, 292 y el código del microsite de la consulta anterior.
Una vez realizada la indexación sobre estos microsites, pasadnos de nuevo el log por si tenemos que realizar algún ajuste antes de realizar otra indexación completa.
Necessitau que passem la rev https://github.com/GovernIB/gusite/commit/be2224c14028c56cb3b280ef8f14996c2b2749ad abans de llançar la indexació sobre els microsites 264, 282, 292?
Si, por favor. Necesitamos que se suba la versión be2224c y posteriormente la indexación
select * from gus_micros where MIC_TIPO_ACCESO is null;
sobre l'entorn de PRE.
export gusite pre.xlsx. A producció no retorna registres./app/caib/gusite/arxius/3888/
select mnu_miccod from gus_menu where mnu_codi in (select con_mnucod from gus_conten where con_codi = 26347 );
es miccodi 1505Per altra banda, no em deixa llançar la indexació individual de microsites en paral·lel, em diu "que ja hi ha una indexació activa". Entenc que això no hauria de passar.
Respecto al tipo de acceso, si te parece correcto, vamos a proceder a incluir la restricción de no nulo y a poner un valor a los microsites con dicho valor a nulo en PRE. ¿Puedes confirmarnos si ves correcta esta modificación?
Los microsites deberían estar con UA, no sé si puedes hacer una consulta de cuantos microsites hay sin UOs, porque sin ello, no se podrían indexar por el pathUO. Meteremos una validación específica para este caso.
Si no existe el directorio /app/caib/gusite/arxius/3888/ , está correcto la indexación. Nos había preocupado al no encontrar los archivos. Igualmente, se debería de tener en cuenta de realizar un proceso de normalizar los ficheros al almacenarlos (sustituir espacios por guiones bajos, quitar acentos, etc...).
Ok, nos comentáis la indexación como ha ido de los 4 microsites (y a ser posible, pasarnos el log de jboss y de ejecución de la indexación).
No puede haber más de una indexación activa. Si alguna indexación se queda colgada se puede cancelar desde el indexar principal.
Us adjunt resultat de la indexació i log del servidor d'aplicacions dels microsites sol·licitats després d'haver desplegat la darrera versió. http://tn.caib.es/Tq3tdQ7N Respecte al tema de la indexació activa, us confirm que només es pot llançar una indexació per microste alhora (quan n'acaba una pot et permet llançar l'altre, si no et diu que ja hi ha un job d'indexació actiu)
Una cosa més, a primera hora del matí el servidor de SOLR de PREproducció havia caigut (en el log del Jboss veureu error 503 per això) no sabem molt bé el motiu. Una vegada reiniciat el servei la indexació ha anat bé
Em pareix bé que s'afegeixi restricció (BBDD + aplicació) perquè es controli que tot microsite tingui un tipus d'accés (he comprovat que a producció tots els microsites en tenen) Pel que fa a l'obligatorietat d'UA, és més delicat i s'hauria de comprovar si quan no està actiu el pluggin d'integració amb ROLSAC també associa una UA per defecte (crec que sí). A producció tots els microsites tenen UA.
La sql a ejecutar en BBDD de PRE:
update gus_micros
set mic_tipo_acceso = 'P'
where mic_tipo_acceso is null;
Executat update sobre PREproducció (4 files actualitzades). M'indicau per favor si donau la incidència per resolta ? Pujam la versió https://github.com/GovernIB/gusite/commit/634df2a229e769521485c8fffbeceffd9285a555 i fem de nou una indexació completa?
Hemos subido un cambio, se debería indexar el microsite 292 y obtener los logs de la indexación y del log de jboss.
Desplegada versió https://github.com/GovernIB/gusite/commit/8134ac0 i llançada indexació sobre el microsites 292 Segueixen havent-hi errades d'indexació i en el log s'observen problemes amb la gestió de connexions Es remeten logs per correu electrònic.
Después de revisar el log de ejecución de la indexación del microsite 292, tras ver los errores de conexión, pensamos que el problema se debe a que la indexación de un microsite se realiza en una única transacción por lo que depende del tamaño de un microsite se pueden producir timeout en las transacciones.
No obstante la exportación del microsite para verificar el problema. Una vez confirmado el problema, procederemos a plantear dividir la indexación de un microsite por partes (contenidos, agendas, noticias...) cada una en una transacción distinta. Aún así, podría existir el problema que una sola de las partes produzca el problema si es excesivamente grande (por defecto, el tiempo de timeout de una transacción en jboss es de 5 minutos).
Otra forma de contrastar el error es debido al timeout de transacciones es ver si en el entorno de pre se puede aumentar el tiemout de la transacción para comprobar que no se produce el problema (por ejemplo, de 5 minutos a 15 minutos). El fichero a tocar se encuentra ubicado en
\server\default\deploy\transaction-jboss-beans.xml , propiedad de 300 pasarlo a 900:
<property name="transactionTimeout">300</property>
L'exportació del microsite 292 són 350MB, si ho descarregau voltros mateixos millor (no sóc a l'oficina i per pujar 350MB hi puc estar tot el matí). https://appsproves.caib.es/sacmicroback/index.do?idsite=292
Per altra banda, les operacions haurien de ser molt més atòmiques en lloc d'una sola transacció per tipus de contingut, és a dir, operacions curtes tipus indexar_arxiu o indexar_pagina_contingut. A priori no veig perquè hem d'aplicar transaccionalitat per desfer en bloc la indexació per un tipus de contingut, la indexació d'un arxiu o una pàgina pot ser perfectament vàlida amb independència de si fallen o no la resta de continguts del tipus. A més a més SOLR ho tracte de manera independent. Corregiu-me si m'equivoc.
Está comiteado el código separando de manera unitaria cada indexación para evitar el problema con el timeout de las transacciones, se debería de volver a indexar el microsite 292.
Pareix que ara sí que és correcte. Tampoc apareixen error en el log del servidor d'aplicacions.
Microsite 292:M08102117051316386040
-Anem a desindexar el microsite arrel.
-Anem a indexar els components
** Arxius:
**** Total arxius 664 (Incorrectes:0)
** Enquestes:
**** Total enquestes 0 (Incorrectes:0)
** Faqs:
**** Total faqs 0 (Incorrectes:0)
** Noticies:
**** Total noticias 0 (Incorrectes:0)
** Agendas:
**** Total agenda 0 (Incorrectes:0)
** Continguts:
**** Total continguts 36 (Incorrectes:0)
Si us pareix llançaré una indexació completa sobre l'entorn de PREproducció abans de passar la versió a producció
Sería buena idea como comentas realizar la reindexación completa antes de pasar a producción. Cuando podáis, nos pasáis los logs del jboss y de la indexación.
Tened en cuenta que debido a la cantidad de microsites, se demora bastante la indexación.
La indexació completa de microsites no acaba. Endemés s'engeguen el job d'indexació automàtica no té en compte si ja hi ha altres indexacions amb execució Adjunt captura de pantalla Remet log d'indexació per correu electrònic