3 ms·

What about the other drawbacks mentioned in the article, like connection draining and error messaging?

by cle 5y ago

lmilcin 5y ago
Well, connection draining is no harder than with normal connections. I think of this problem following way: you already have to design your system to be able to handle network faults and node crashes. So just kill the node and rely on existing solution to handle the error. This also gives the opportunity to test your fault handling logic. Error messaging is a little bit more complicated. At first sight, in normal request-response you get either successful response or an error. But if you look a little bit closer, in fact you get 200 response header followed by response data, which may itself fail to be transmitted. So technically you already need to be able to resolve an error that happens after you have received 200 header. In case of streaming response the difference is not in how the response is being sent to the client but how the client is processing it. The client has option to wait for entire response (header followed by entire stream of data) and only start processing the response after entire response has been received. This is no different from a normal, non-streamed request response. The client also has option to start processing the response while it is being received. The response does not need to be streamed from the server nor it needs any kind of streaming protocol. I have been stream-processing XML responses two decades ago with no special streaming support. One solution I use is that is that the client architecture treats this data as speculative meaning that an error can undo entire batch received. Another solution is that the design is such that the data makes sense even partially received, the processing of response is idempotent and the client will be asking, ad infinitum, to receive the rest of the response until the call succeeds. This of course has its own reliability problems (what if the error is permanent?)

What about the other drawbacks mentioned in the article, like connection draining and error messaging?

by cle 5y ago

What about the other drawbacks mentioned in the article, like connection draining and error messaging?

Well, connection draining is no harder than with normal connections. I think of this problem following way: you already have to design your system to be able to handle network faults and node crashes. So just kill the node and rely on existing solution to handle the error. This also gives the opportunity to test your fault handling logic. Error messaging is a little bit more complicated. At first sight, in normal request-response you get either successful response or an error. But if you look a little bit closer, in fact you get 200 response header followed by response data, which may itself fail to be transmitted. So technically you already need to be able to resolve an error that happens after you have received 200 header. In case of streaming response the difference is not in how the response is being sent to the client but how the client is processing it. The client has option to wait for entire response (header followed by entire stream of data) and only start processing the response after entire response has been received. This is no different from a normal, non-streamed request response. The client also has option to start processing the response while it is being received. The response does not need to be streamed from the server nor it needs any kind of streaming protocol. I have been stream-processing XML responses two decades ago with no special streaming support. One solution I use is that is that the client architecture treats this data as speculative meaning that an error can undo entire batch received. Another solution is that the design is such that the data makes sense even partially received, the processing of response is idempotent and the client will be asking, ad infinitum, to receive the rest of the response until the call succeeds. This of course has its own reliability problems (what if the error is permanent?)