Ok. let me explain the complete scenario
1) I have a gRPC server which provides a server streaming RPC, my
application is a client which needs to invoke this RPC and keep listening
to the data written by the server (until the RPC is closed).
The problem here is that in the server side if they detect that the
connection has problem (while writing the data to the RPC), they consider
this RPC as closed and *client need to re-invoke it**.*
In grpc java 1.0.1 i don't have mechanism in client to know the
connection was broken and i need to restart the RPC.
I have done some test, when we stop the server, in client side
streamobserver, the overloaded method warning(String msg, Object... params)
is invoked
But when i disconnect the network between client and server, the server
can get to know but client doesn't get to know about it and the observer
keeps on idle.
2) I am using NettyChannelBuider to build the channel with the gRPC
server, (I hope all types of channelbuilder uses http2)
3) If somehow I can convince the product team to upgrade the grpc-java
version, will it be able to communicate with c based grpc 1.0.1 version
server?
On Wednesday, June 21, 2017 at 11:56:59 PM UTC+5:30, Eric Anderson wrote:
>
> On Wed, Jun 21, 2017 at 3:10 AM, <deepakag...@gmail.com <javascript:>>
> wrote:
>
>> Hi Eric, thanks for the response but i have to problems
>> 1) I am using grpc-java 1.0.1 which does not support this Interface (The
>> product team has decided on grpc version)
>>
>
> Sorry, but the feature wasn't available in 1.0.x.
>
> The only workaround in that case is to send "noop/trash" messages/RPCs
> periodically. Basically, TCP needs *writes* in order to discover *read*
> failures,
> so you generate noop writes on the TCP connection. If you receive GOAWAY
> from the server (like during server shutdown or server rotation), then any
> new RPCs will use a different connection, thus won't help you detect if the
> old connection is broken. Depending on your setup, that may not be much of
> a problem (e.g., if the server closes the connection soon after sending the
> GOAWAY). Using noop messages on the same RPC stream (by making it a bidi
> streaming RPC) wouldn't have that deficiency, but you'd also need to do the
> noop messages on all active streams and have to change more of your
> application logic.
>
> 2) The keepalive time is not fixed.
>>
>
> I don't understand this.
>
> Also i have a doubt about the whether grpc java 1.0.1 can support http2. I
>> found c based grpc 1.0.1 and grpc-java 1.0.1 has many different functions
>>
>
> I don't understand what you mean by functions. Could you explain more? It
> sounds like this is unrelated to the network break detection.
>
--
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/6e76eb90-455b-4a0b-9f6c-c88ba45f3a8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
