Expose identifier for a connection bundle
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- haskell
- Área
- distributed-systems
Línea de trabajo
Comienza rastreando cómo Connection, ErrorEvent y receive gestionan los eventos de pérdida y apertura de conexiones. Define cómo se propaga ConnectionBundle a través de las rutas de conexión afectadas y, a continuación, verifica que los eventos de pérdida identifiquen el bundle relevante y se observen antes de las aperturas posteriores con el mismo peer.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
-- Identifies a "heavyweight" connection which carries 0 or more "lightweight"
-- connections.
type ConnectionBundle = Word32
data ErrorEvent =
...
-- EventConnectionLost indicates which bundle was lost
| EventConnectionLost EndPointAddress ConnectionBundle
...
data Connection = Connection {
...
-- Each connection knows which bundle carries it.
, bundle :: ConnectionBundle
}
Why?
When a connection is lost, an EventConnectionLost peer must be posted and ultimately come out of receive at that end point before any ConnectionOpened events to the same peer. While that event sits in the queue, new connections may be established to that same peer. Once the EventConnectionLost peer comes out of the queue it's impossible to determine which of the existing outbound lightweight connections are affected by it. By including a ConnectionBundle on every Connection and on the EventConnectionLost, it's possible to determine whether an outbound connection has been severed without trying to send on it.
- Lenguaje dominante
- Haskell
- Estrellas
- 753
- Forks
- 101
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de haskell-distributed/distributed-process
-
failed to build with time-1.15Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#486 · 1 comentario · 1 reacción ·
-
discuss enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#478 · 4 comentarios · 3 reacciones ·
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
haskell-distributed/distributed-process#476 · 2 reacciones ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationQuizá libre de nuevo @LaurentRDC la tomó hace 481 días y no hay ningún pull request abierto. Abiertoenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 reacciones · 1 asignado ·
Todos los issues de haskell-distributed/distributed-process
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
objectionary/phino#2059 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
NixOS/nixpkgs-update#586 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
koalaman/shellcheck#3593 ·
-
Make node sockets moduleAbiertoconfiguration
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
tweag/cardano-kosmos#47 ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 3 días