bigtable getRows sometimes causes 'Transport Closed' error

[SenthilKumartd]

table.getRows({ keys: rKs, filter: rangeFilter }).then((loadedRows) => {
  let result = [];
  //code follows...
})

Error details:

Error: {"created":"@1488456924.703000000","description":"Transport close
d","file":"..\src\core\ext\transport\chttp2\transport\chttp2_transport.c","file_
line":1072}

This error is shown not all the time, but keeping some time idle the browser and accessing getRows throw this error. I am not able get any help regarding this. Can you please help to resolve this error?

[callmehiphop]

@murgatroid99 this looks like a gRPC message. I'm assuming this happens because the channel closes due to inactivity, is there a way to specify a timeout? Or do we just need to create a new channel?

[murgatroid99]

It is possible to set a timeout on a single call, but I don't think it will help here. You can also set the client to use HTTP2 ping to keep the TCP connection alive. This can be set up using the third argument to the Client constructor, which is a map whose keys are defined at https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L148.

You should be able to set the HTTP2 ping up using "grpc.http2.min_time_between_pings_ms" and "grpc.http2.max_pings_without_data".

[callmehiphop]

@murgatroid99 awesome, thanks for the tips!

/cc @jmuk

[callmehiphop]

@murgatroid99 I'm not having any luck getting ping to work, I've tried several combinations of configurations but I continue to get a transport closed error. Any thoughts on this?

[murgatroid99]

A few of the other arguments may also be relevant. It may help to modify "grpc.http2.keepalive_time" and "grpc.http2.keepalive_timeout", and also to set "grpc.http2.keepalive_permit_without_calls" to 1.

[jmuk]

@callmehiphop is it possible for users to pass those grpc options in bigtable APIs? like, require('@google-cloud/bigtable')({'grpc.http2.keepalive_time': time})?

[murgatroid99]

After discussing this with @ctiller, I realized that the solutions I recommended may not actually work. GFEs limit the number of HTTP2 pings they respond to per connection, so trying to repeatedly ping them may not actually accomplish anything.

gRPC can actually correct for TCP connections dying, but only if there are any pending gRPC events. This is why others have reported that repeatedly doing SELECT 1 fixes this problem. It should also be possible to achieve this by keeping a streaming call open forever, though that may be undesirable for other reasons.

One alternative solution would be to downgrade to gRCP 1.1.1. That has some different internals that, among other things, should remove the requirement that there are pending events to detect TCP connection failure. Unfortunately, the changes in that version had to be reversed to fix #1946. I'm hoping to reintroduce them soon with the bugs ironed out.