Nice, this looks solid to me :).
On Friday, July 23, 2021 at 4:42:12 AM UTC-4 amits...@gmail.com wrote:
>
>
> > On 11 Jul 2021, at 10:37 am, Amit Saha wrote:
> >
> > Hi all,
> >
> > I am implementing a reconnection logic in my client for a bidi RPC
> method.
> >
> > This is similar to what
>
> On 11 Jul 2021, at 10:37 am, Amit Saha wrote:
>
> Hi all,
>
> I am implementing a reconnection logic in my client for a bidi RPC method.
>
> This is similar to what
> https://stackoverflow.com/questions/66353603/correct-way-to-perform-a-reconnect-with-grpc-client
> seeks to do. The summary
On Wednesday, July 14, 2021 at 3:53:40 PM UTC-7 amits...@gmail.com wrote:
> Thanks, I am able to understand what you are proposing. With this
> approach, when I try to Send() with the stream disconnected, then the
> operation will either exit - which is not what I want, or wait for the
> recv()
On Thu, Jul 15, 2021 at 3:43 AM 'dfa...@google.com' via grpc.io
wrote:
>
> Only your send _or_ recv path should be recreating the stream. I think I
> would implement this as:
>
> - goroutine performing Send exits on any error (or encounters the error then
> blocks on a channel until the next st
Only your send _or_ recv path should be recreating the stream. I think I
would implement this as:
- goroutine performing Send exits on any error (or encounters the error
then blocks on a channel until the next step...)
- goroutine performing Recv re-creates the Send goroutine if needed (or
unb
