Open arieljlira opened 1 year ago
@arieljlira Sí, hace poco hice yo esa nueva implementación porque las queries con ventanas grandes nos estaban tirando los solr en otros repos grandes. Entones ahora la estrategia es esta búsqueda en ventanas de 1 día en forma incremental. Creo que el problema es que no altere el timestamp al llegar al maxDaysToLookAhead. Le pusimos 30 entendiendo que si pasaba un caso como el tuyo manualmente podés adelantar el timestamp ejecutando con -f nuevamente. Que te parece pongo que en los casos donde llega a max haga un update del timestamp al terminar ? Eso haría que en el proximo run siguiera buscando para adelante otros 30 días, eventualmente recorrería hasta encontrar algo o estar al día. Me interesa tu opinion. Gracias y saludos
Hola Lautaro, si, hacer el guardado del timestamp al completar la ventana solucionaría el problema de base. Es decir, sería cuando retryToLookAhead == self.maxDaysToLookForEvents
En cuanto al incremento de 1 día capaz se podría probar con una estrategia exponencial. Ej
retryToLookAhead=retryToLookAhead*2
En general en los cores no hay blancos, y cuando los hay son de varios días.
Saludos y gracias!
Confirmo que avanzando un poco el lastTrackedEventTimestamp
de dspace-stats-collector/var/timestamp/default.dat
(hasta el cierre de la ventana), soluciona el problema.
Perfecto, de todas maneras procederemos a implementar lo que discutimos, muchas gracias. Lautaro Matas @.***
El 23 feb 2023, a las 12:59, Ariel Lira @.***> escribió:
Confirmo que avanzando un poco el lastTrackedEventTimestamp de dspace-stats-collector/var/timestamp/default.dat (hasta el cierre de la ventana), soluciona el problema.
— Reply to this email directly, view it on GitHub https://github.com/lareferencia/dspace-stats-collector/issues/30#issuecomment-1441639038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH7G6UF6GDNU5ATGR5BCFTWY5GIXANCNFSM6AAAAAAUWSCZ54. You are receiving this because you are subscribed to this thread.
En CIC-DIGITAL (dspace7) https://digital.cic.gba.gob.ar/ tenemos eventos registrados desde 2014. Dado que este módulo de DSpace tuvo varias fallas en el pasado, tenemos intervalos/ventanas de tiempo en los que no se registraron eventos o sí pero debieron ser eliminados.
Ahora tenemos un caso puntual del stat-collector procesando correctamente los eventos hasta que llegó al 2020-08-03, momento en el cual comienza una ventana de 80 días sin eventos. Ahí, se quedó colgado hace meses y cada vez que se levanta desde la cronjob, consulta por los mismos días y termina, quedándose en este punto para siempre.
Creo que el problema se da en https://github.com/lareferencia/dspace-stats-collector/blob/master/dspace_stats_collector/solrinput.py#L87 con las variables retryToLookAhead y self.maxDaysToLookForEvents (30). retryToLookAhead comienza en 1 e incrementa de a 1 cada vez que resulta en una página sin documentos hasta llegar a maxDaysToLookForEvents . Cuando esto sucede termina y no procesa más. Agrego log de ejemplo.