Crónica de un poblema "divertido"
En la DNA , tenemos un Wiki Interno y otro Wiki Externo. Cuando se da por aprobado un procedimiento en el wiki interno, el mismo se publica en el wiki externo a traves de web services.
Los mismos venian funcionando sin problemas, desde hace varios meses, pero los usuarios nos plantearon que se habia empezado a "quedar congelado" en varias oportunidades.
Hicimos un TRACE para ver donde se estaba poniendo lento y en el mismo vimos, al querer visualizar una pagina
16:50:54,187 [12] DEBUG GxConnectionCache - SetAvailableCommand stmt:
SELECT PageUsageDay, PageUsageCount, PageId FROM wikiproc.PageUsage
WHERE PageId = :PageId AND PageUsageDay = :PageUsageDay ,c.opened:0=0
16:50:54,187 [12] DEBUG GxConnection - DecOpenHandles, OpenHandles after '1'
16:50:54,187 [12] DEBUG GxConnectionManager - GxConnectionManager.DecOpenHandles
handle '783', datasource 'Default', openhandles 1
16:50:54,187 [12] DEBUG GxConnection - Start Monitor.Exit 59118305
16:50:54,187 [12] DEBUG GxConnection - End Monitor.Exit 59118305 executingCursors:1
16:50:54,187 [12] DEBUG Indexer - Indexer Enqueue waiting...
16:51:10,745 [12] DEBUG GxCommand - Start GxCommand.Close idatareader
16:51:10,745 [12] DEBUG GxDataReader - Close GxDataReader, open:True
16:51:10,745 [12] DEBUG GxConnectionCache - SetAvailableCommand stmt:
SELECT PageUsageDay, PageUsageCount, PageId FROM wikiproc.PageUsage
WHERE PageId = :PageId AND PageUsageDay = :PageUsageDay
FOR UPDATE OF PageUsageCount NOWAIT,c.opened:0=0
16:51:10,745 [12] DEBUG GxConnection - DecOpenHandles, OpenHandles after '0'
16:51:10,745 [12] DEBUG GxConnectionManager - GxConnectionManager.DecOpenHandles
handle '783', datasource 'Default', openhandles 0
16:51:10,745 [12] DEBUG GxConnection - Start Monitor.Exit 59118305
Revisando con mas detalle, vimos que la actualización se hacia con un Business Component, pero que no hacia referencia al indice o al Full Text Search para nada.
Seguimos revisando y encontramos que la propiedad SEARCHEABLE, que habilita el Full Text Search en la aplicacion estaba en TRUE. Esto hace que todos los BC graben en el indice de Lucene, cuando se salva.
Revisando un poco la historia del problema, vimos que habíamos cambiado dicha propiedad, solamente para poder identificar en el web.config cual era la linea que hacia referencia a la posición del Lucene Index, pues la empresa que administra los Web server nos había pedido que los cambiáramos de lugar.
Teniamos que cambiar esto y ponerle (cambiar el .. por .)
<add key="LUCENE_INDEX_DIRECTORY" value="..\LuceneIndex" />
Luego, de hacer el cambio, el mismo no se deshizo (ahí estuvo la causa del problema).
Haciendo un resumen
1) Nos piden que cambiemos el directorio LuceneIndex de lugar.
2) Se cambia la propiedad de Seacheable a nivel del Ambiente, para generar el web.config con la entrada
3) Cambiar el la ubicacion del indice Lucene
4) NO VOLVER LA PROPIEDAD SEARCHEABLE a FALSE (acá esta el problema).
5) Regenerar algunas transacciones (que no cambiaron)
6) Instalar dichos objetos (se hace varios días después, pues como nada habia cambiado, no se instalaron enseguida).
7) Se empieza a tener problema con el wiki, cuando mas de una persona trabaja en el mismo.
Que conclusión sacamos de esto?
La mas obvia es que las propiedades a nivel de ambiente, muchas veces pueden generar grandes cambios de comportamiento, aunque no se cambie nada a nivel de objetos. Hay que tener mucho cuidado con ellas.
Seria importante poder tener la historia de las mismas y también quien las cambia de forma de poder auditarla al igual que cualquier otro objeto de la KB.
La programacion basada en modelos (como los usados con GeneXus) tiene la potencia de adaptarse a diversos ambientes cambiando propiedades, pero como toda cosa con mucha potencia, debe ser usada con mucho cuidado. Como dice Spider Manel hombre araña:
"With great power comes great responsibility."
Excelente las conclusiones!!
ResponderBorrarDe todas formas... esto no va par dar palo sino para ver de si no hay algo a mejorar.
¿no tiraba un error al no encontrar el indice?
¿porqué demoraba tanto? bloquea la ejecución de todo?
tiene que ser necesario llegar a usar un TRACE para detectar un problema tan "simple" como ese?
El indice lo encontraba y lo creaba bien. Lo que pasa es que el proceso de indexado solo indexa uno por vez, si hay otro usuario indexando, espera que el otro termina.
BorrarNo se de que otra forma nos hubiésemos dado cuenta si no era usando el TRACE. Viendo el código GeneXus(que no había cambiado) no era fácil llegar a saber que era lo que estaba pasando. En la base de datos, tampoco había bloqueos, en IIS no tenia problemas... La CPU y el Disco funcionaban sin inconvenientes...
Lo que había cambiado era una propiedad de toda el ambiente y no es fácil detectar dichos cambios, solo mirando la KB.
"Lo que pasa es que el proceso de indexado solo indexa uno por vez, si hay otro usuario indexando, espera que el otro termina."
ResponderBorrarEso me suena a un problema a solucionar ;)
Sobre los archivos de configuración, la que me imagino es que pueden usar algo como GIT de por medio para tener control de cambios.
Si el folder de producción es un montado de git, inclusive puedes comparar y detectar aquellos toques que se hagan por fuera de git para identificarlos, hacer revert o ver de versionarlo como un toque oficial enviándolo al server GIT.
Si, hay varias cosas para solucionar, pero lo primero es no ejecutar cosas innecesaria.
BorrarCon respecto a la configuracion, no son archivos, sino que son propiedades de la base de conocimiento, que pueden o no terminar en los archivos de configuracion. Para poder hacer un seguimiento de los cambios, se deberia hacer una extension que cuando alguien salve una propiedad, se salve en un archivo de texto dentro de la misma KB, de forma de tener historia de quien salvo y cuando.
Tambien deberia poder consultar las diferencias entre las diferentes revisiones.