FYI: 3.0.0-pre1 includes support for auto-idling Channels (and keepalive for OkHttp). So you may be able to simplify your code now.
On Sun, Jun 26, 2016 at 1:01 PM, Eric Anderson <ej...@google.com> wrote: > Whew. I saw your email this morning but didn't have time to reply saying I > had so clue what could cause that. Glad it's working for you, and you can > look forward to built-in idleness. > > And an hour makes sense for the tcp connection to (silently) break with a > home network, since there is a NAT involved. > On Jun 26, 2016 12:29 PM, "Taehyun Park" <gold.dest...@gmail.com> wrote: > >> Sorry for confusions. The logcat was not the same device and the timer I >> added didn't work properly. Releasing resources by shutting down a channel >> when there is a period of inactivity solved my issue. >> >> On Sunday, June 26, 2016 at 1:06:06 AM UTC+9, Eric Anderson wrote: >>> >>> On Sat, Jun 25, 2016 at 4:36 AM, Taehyun Park <gold.d...@gmail.com> >>> wrote: >>> >>>> I'm using grpc java on Android and I found a very weird issue. After a >>>> certain period a ManagedChannel no longer works. >>>> >>> >>> Was that after a period of inactivity? Were you on good WiFi (one that >>> you trust), bad WiFi, or cellular? >>> >>> I instantiated a ManagedChannel when there is no cached channel then >>>> cache it until the number of active channels is 0. My app worked fine and >>>> didn't have a problem when it's launched. but all grpc calls stopped >>>> working after a certain period. The app wasn't closed but it was in a >>>> backstack. >>>> I searched a similar issue in grpc issue tracker on github but I'm not >>>> sure if https://github.com/grpc/grpc-java/issues/1636 and >>>> https://github.com/grpc/grpc-java/issues/1648 are the issue I'm having. >>>> >>> >>> When discussing keepalive, the general assumption is the network >>> misbehaved (which is not uncommon on mobile). Keepalive is only going to be >>> active when an RPC is outstanding. That means that it will need to be >>> combined with channel idleness to close TCP connections after inactivity. >>> >>> https://github.com/grpc/grpc-java/issues/1972 >>> https://github.com/grpc/grpc-java/issues/1276 >>> >>> Both are planned for 1.0 in order to give a full solution to this sort >>> of issue (assuming that failures are due to poor networks). Idleness in >>> general is useful. With it you really don't have much reason to cache the >>> channel like you were. You could create the channel eagerly (which starts >>> IDLE) and the channel can release resources when there is a period of >>> inactivity. >>> >> -- >> 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. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/grpc-io/2b885e4d-abef-4658-a6e9-45c9a4cd967e%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/2b885e4d-abef-4658-a6e9-45c9a4cd967e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit 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. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oO7rFauxeRQ8g7psNF9%2BpkR2F%3D60F9JR2%3DsVGbYthkchw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
