Mecanismo de timeout y retries en los envios a IOTAs

[fgalan]

Viene de #70 (comment)

Con respecto a time_sleep, también por homogeneidad haría como en el caso del CB: renombrarlo a sleep_send_batch con un valor por defecto (en el cb es 0, es decir no se espera entre envíos) y definido en el constructor para no repetirlo en las llamadas send_json y send_batch. Por otro lado, en entornos productivos es posible que se produzcan microcortes de conexión cuando se quieren enviar datos, sería aconsejable incorporar un mecanismo timeout/try similar al que se usa en el caso del CB, que tenemos un timeout (10 por defecto), post_retry_connect (3 por defecto), post_retry_backoff_factor (20 por defecto) definidos en el manager, que se pueden modificar a través del constructor y que send_batch (en este caso send_json) le da uso, en caso de tener timeouts hacer un número de retrys automáticamente, dará estabilidad en el envío de esos datos.

Este mecanismo de timeout/try queda pendiente de implementar, motivo por el cual creamos este issue.

(Los nombres de los métodos referidos arriba pudieran ser distintos a los definitivos, según evolucione la PR #70)

CC: @xavi12p @CeciliaFili

[xavi12p]

Se hace el cambio y se pide PR: #85

[fgalan]

Issue completada en la citada PR. Lo cerramos.

@xavi12p @CeciliaFili, ¿cerramos versión 0.12.0 con esto? ¿O vais a incorporar algún fix más antes de que vayamos a cerrar versión? Lo que nos digáis...

[xavi12p]

Hola, nosotros no tenemos previsto incorporar ninguna otra mejora. Se puede cerrar versión y publicar. Nos avisáis cuando esté publicada? Nos interesa esta funcionalidad para una ETL que hace envíos a plataforma vía IoTAgent. Gracias!! @fgalan

[fgalan]

Ya estaría cerrada y publicada la nueva versión:

https://pypi.org/project/tc-etl-lib/0.12.0/