Repository navigation
Conversation
f794845 to
9b743c1
Compare
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
9b743c1 to
161cf56
Compare
| OutboundEnvelope { | ||
| StreamId stream_id // 0 for ControlMessageBuilder | ||
| CallMessageBuilder | ControlMessageBuilder builder | ||
| } | ||
|
|
||
| InboundEnvelope { | ||
| StreamId stream_id // 0 for ControlMessageView | ||
| CallMessageView | ControlMessageView view | ||
| } |
There was a problem hiding this comment.
in theory the flatbuffer objects contain the stream id, so do we need this actually
| - stream `0` goes to the control-stream pending list; | ||
| - an envelope for a known nonzero `stream_id` goes to that stream's pending | ||
| list; | ||
| - an opening message for a never-created odd stream creates an inbound-call |
There was a problem hiding this comment.
we cant simply say odd, it depends on what kind of context we have
|
|
||
| ## Close and ID lifetime | ||
|
|
||
| The worker-owned call registry keeps a closed-stream set keyed by `stream_id`. |
There was a problem hiding this comment.
I would like to avoid storing all closed stream id. We already remember stream ids for open calls and we could remember the highest used stream id for each side and reject any messages for stream ids that are smaller and not open
# Conflicts: # doc/design/v2/runner/README.md
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
|
| an abnormal call termination. Without `Error`, it is normal termination. After sending or receiving `CloseCall`, the | ||
| local endpoint sends no further call-scoped traffic on that stream. Messages already in transit may still arrive after | ||
| either event; the endpoint ignores those late stream messages while still processing a received `CloseCall`. | ||
| either event. The low-level context discards delayed messages for inactive peer-owned stream IDs as described in the |
There was a problem hiding this comment.
protocol does not know about the context
| Sending or receiving `CloseCall` makes the local endpoint's outbound direction terminal: it sends no further schema, | ||
| batch, send budget, `Reset(...)`, or other call-scoped message. A `CloseCall` is not acknowledged. Messages already in flight may | ||
| still arrive after either endpoint sends or receives `CloseCall`; late messages for the closed stream are ignored. | ||
| still arrive after either endpoint sends or receives `CloseCall`. Delayed messages for inactive peer-owned stream IDs |
There was a problem hiding this comment.
protocol doesnt know about runner
| The worker-owned call registry keeps a closed-stream set keyed by `stream_id`. Closing a call records its stream ID | ||
| before releasing its pending sequence, so delayed messages can be discarded without confusing them with a new call; | ||
| stream IDs are never reused on a connection. | ||
| The worker-owned call registry tracks active streams and the high-water state described in |
| does not own `Call` or `ControlStream` instances and does not dispatch to | ||
| worker-facing objects. | ||
|
|
||
| ## Stream-ID ownership and allocation |
There was a problem hiding this comment.
this basically a copy from the protocol



Fixes #109