Crónica de un poblema "divertido"

Tenemos funcionando varios wikis (www.gxwiki.com) todos con configuraciones/versiones parecidas. C#/SQL server y C#/Oracle.

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


Estaba demorando 16 segundos en indexar algo. Lo raro es que no se estaba salvando la pagina y lo único que estaba haciendo es registrar el acceso a la pagina, para poder tener luego estadísticas de cuales son las paginas mas leídas.

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."

Comentarios

  1. Excelente las conclusiones!!

    De 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?

    ResponderBorrar
    Respuestas
    1. 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.

      No 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.

      Borrar
  2. "Lo que pasa es que el proceso de indexado solo indexa uno por vez, si hay otro usuario indexando, espera que el otro termina."

    Eso 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.

    ResponderBorrar
    Respuestas
    1. Si, hay varias cosas para solucionar, pero lo primero es no ejecutar cosas innecesaria.

      Con 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.

      Borrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.