Receiving Stream CANCELLED error during the bidirectional streaming

[FastLabs]

Hi all

I am new to armeria and I am working on a simple pin-pong bidirectional streaming service and I receive stream cancelled after about 14 seconds. I took the simplest example for the implementation (i tried the example from armeria examples folder with hello service).

I tried also different timeout options on client and server and unfortunately i didn't see any difference. Could someone help me troubleshoot the problem please?

[schiemon]

Hi @FastLabs!
Do you mind to provide us with some information about the intended configuration of your client and server? Especially, did you consider the client-side/server-side request/response timeout and client-side/server-side maximum request and response length? Those are limiting the stream duration and volume.
I achieved to stream for about 2 minutes with the example code you mentioned: https://gist.github.com/schiemon/03b1c73e836812f50a344e0b1d222094

[FastLabs]

hi @schiemon thanks for coming back. Indeed i had to go and review the code and I was miss-using the timeout configuration on the client side.

Once I set the correct value with -Dcom.linecorp.armeria.defaultResponseTimeoutMillis i managed to solve my issue. The error status was confusing on the server site. Thanks for the example

[schiemon]

Glad to help

[schiemon]

@FastLabs Do you mind to change the state of the question to answered?

[FastLabs]

Hi @schiemon basically I came across to the issue when I am adding a decorator for example a retry rule. Does a decorator can affect how the responseTimout value is set?

GrpcClients .builder(uri()) .responseTimeoutMillis(0) .decorator(RetryingClient.newDecorator(...)) .build(HelloServiceStub.class);

when i add the decorator I am getting DEADLINE_ESCEEDED exception

[schiemon]

@FastLabs Try to set responseTimeoutMillisForEachAttempt to zero. Per default it is set to 15 seconds. I need to think whether we want to leave it like that

        return GrpcClients
                .builder(uri())
                .responseTimeoutMillis(0)
                .decorator(
                        RetryingClient
                                .builder(RetryRule.failsafe())
                                .responseTimeoutMillisForEachAttempt(0)
                                .newDecorator()
                )
                .build(HelloServiceStub.class);

[schiemon]

You might want to consider to extend the lifetime of the response manually on every message however. Otherwise you can run into resource exhaustion issues. You could do that with ctx.setResponseTimeoutMillis.