Support `chunk` option to enable "at-least-once" delivery

Abierto
#120 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
distributed-systems

Línea de trabajo

Comienza leyendo la implementación de FluentSender, especialmente su búfer pendings y el comportamiento del valor de retorno de emit(), y compáralos después con la sección de opciones de Forward Protocol Specification v1. Define cómo deben funcionar la compatibilidad con chunks, los reintentos, los resultados de entrega y la compatibilidad con el buffer_overflow_handler existente; se considerará terminado cuando el diseño y los límites de compatibilidad se hayan acordado antes de la implementación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Background

According to the "Forward Protocol Specification v1", fluentd supports an option named chunk which enables at-least-once delivery of messages.

This option is very useful in cases where data loss is not acceptable.

https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1#option

The problem

The current design of fluent-logger-python, however, makes it difficult to support this new option.
Specifically:

  1. Events are buffered inside FluentSender class as a single bytes sequence (self.pendings). There is no efficient way to reconstruct a specific event from the buffer and resend it.
  2. And this bytes sequence buffer is kinda API. So we cannot moddify the format in which FluentSender buffers messages (at least, casually) or it will break many user-defined buffer_overflow_handlers.
  3. Also for now, we lack a handful of building blocks for supporting the "at-least-once" semantics. For example, there is no reliable mechanism for users to tell if a message has been delivered successfully [^]
So we need to ...

The bottom line is, we need to apply some architectural changes to make this library support the (newly-introduced) "at-least-once" semantics. Of course, we need to do it without breaking many existing programs.

What do you think about this? Or is there already a plan to make this library compliant with the v1 specification?

[^] Yes, FluentSender.emit() is supposed to notify this via its return value. But even if the method returns False, the message might be delivered anyway through the pending buffer, and this "retry" part is totally opaque to users.

Lenguaje dominante
Python
Estrellas
457
Forks
138
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fluent/fluent-logger-python

Todos los issues de fluent/fluent-logger-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.