Yes, it is might be more efficient to use keep-alives rather than destroying
and rebuilding the connections - but that will depend on your setup/usage.
> On Jan 17, 2019, at 2:31 PM, davis.bry...@gmail.com wrote:
>
> After researching a bit, I believe the issue was that the proxy on the server
> was closing the connection after a few minutes of idle time, and the client
> ManagedChannel didn't automatically detect that and connect again when that
> happened. When constructing the ManagedChannel, I added an idleTimeout to it,
> which will proactively kill the connection when it's idle, and reestablish it
> when it's needed again, and this seems to solve the problem. So the new
> channel construction looks like this:
>
> @Singleton
> @Provides
> fun providesMyClient(app: Application): MyClient {
> val channel = AndroidChannelBuilder
> .forAddress("example.com", 443)
> .overrideAuthority("example.com")
> .context(app.applicationContext)
> .idleTimeout(60, TimeUnit.SECONDS)
> .build()
> return MyClient(channel)
> }
> To anyone who might see this, does that seem like a plausible explanation?
>
>
> On Wednesday, January 16, 2019 at 7:30:42 PM UTC-6, davis....@gmail.com wrote:
> I believe I may not understand something about how gRPC Channels, Stubs, And
> Transports work. I have an Android app that creates a channel and a single
> blocking stub and injects it with dagger when the application is initialized.
> When I need to make a grpc call, I have a method in my client, that calls a
> method with that stub. After the app is idle a while, all of my calls return
> DEADLINE_EXCEEDED errors, though there are no calls showing up in the server
> logs.
>
> @Singleton
> @Provides
> fun providesMyClient(app: Application): MyClient {
> val channel = AndroidChannelBuilder
> .forAddress("example.com <http://example.com/>", 443)
> .overrideAuthority("example.com <http://example.com/>")
> .context(app.applicationContext)
> .build()
> return MyClient(channel)
> }
> Where my client class has a function to return a request with a deadline:
>
> class MyClient(channel: ManagedChannel) {
> private val blockingStub: MyServiceGrpc.MyServiceBlockingStub =
> MyServiceGrpc.newBlockingStub(channel)
>
> fun getStuff(): StuffResponse =
> blockingStub
> .withDeadlineAfter(7, TimeUnit.SECONDS)
> .getStuff(stuffRequest())
> }
> fun getOtherStuff(): StuffResponse =
> blockingStub
> .withDeadlineAfter(7, TimeUnit.SECONDS)
> .getOtherStuff(stuffRequest())
> }
> I make the calls to the server inside a LiveData class in My Repository,
> where the call looks like this: myClient.getStuff()
>
> I am guessing that the channel looses its connection at some point, and then
> all of the subsequent stubs simply can't connect, but I don't see anywhere in
> the AndroidChannelBuilder documentation that talks about how to handle this
> (I believed it reconnected automatically). Is it possible that the channel I
> use to create my blocking stub gets stale, and I should be creating a new
> blocking stub each time I call getStuff()? Any help in understanding this
> would be greatly appreciated.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com
> <mailto:grpc-io+unsubscr...@googlegroups.com>.
> To post to this group, send email to grpc-io@googlegroups.com
> <mailto:grpc-io@googlegroups.com>.
> Visit this group at https://groups.google.com/group/grpc-io
> <https://groups.google.com/group/grpc-io>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/1202aad5-4897-4bbb-a238-34edae74e368%40googlegroups.com
>
> <https://groups.google.com/d/msgid/grpc-io/1202aad5-4897-4bbb-a238-34edae74e368%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/1014FB70-8708-42FC-B810-8951D4BF7B99%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
