[grpc-io] grpc and protobuf for coreClr

[dariopb]

Hi,

What is the the right nuget to include for protobuf support to use grpc 
with coreClr? I'm using "Grpc.Core": "1.0.1" but the "Google.Protobuf": 
"3.1.0" fails to install ("the dependency Google.Protobuf > = 3.1.0 could 
not be resolved".

thanks!

Dario

-- 
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/7dea8c3e-d835-436f-a406-0339cf4e5da1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] grpc-java: support graceful server shutdown

[michael . wright]

Thank you Makarand.

Does this imply that a grpc-java server emits a GOAWAY frame on shutdown, 
i.e. on jvm closure?

On Thursday, December 22, 2016 at 8:57:32 PM UTC, Makarand Dharmapurikar 
wrote:
>
> Both Java and C based clients will respect GOAWAY frames, in that a GOAWAY 
> will induce the client to use a different connection for the following 
> requests. Will defer to others for DNS resolver interaction.
>
> On Thu, Dec 22, 2016 at 7:21 AM, > 
> wrote:
>
>> Hello,
>>
>> When we redeploy our servers on AWS, behind an ELB we would like to 
>> support graceful shutdown by pushing a GOAWAY frame to the already 
>> connected clients and initiate a graceful shutdown of the clients 
>> connection to the server. After some amount of time after the GOAWAY frame 
>> has prompted shutdown we would like the clients to re-establish a 
>> connection with the servers. 
>>
>> I see this sort of behaviour implemented in the GO server 
>> https://github.com/grpc/grpc-go/pull/774
>>
>> Is this also implemented in the grpc-java server (a link to the code 
>> would be appreciated) ?
>>
>> Also, we plan to implement a scheduled DNS name resolver for updating our 
>> ELB DNS with the appropriate TTL 
>> https://github.com/grpc/grpc-java/issues/2514 , will the GOAWAY frame 
>> behaviour above effect a scheduled DNS name resolver?
>>
>> Thanks,
>>
>> Mike
>>
>> -- 
>> 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+u...@googlegroups.com .
>> To post to this group, send email to grp...@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/58f821f2-6b8a-4a8b-b20b-a2d744179627%40googlegroups.com
>>  
>> 
>> .
>> 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.
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/8c4ed890-55a2-4159-8191-416545da6e83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Avoiding deserialization

[Chris Cleveland]

I'm using Java. A bit of searching suggests that I have to implement client
and server interceptors to send and receive custom headers. Is that correct?

Also, can I avoid deserialization on the server side and simply forward the
request based on the value of a custom header?

On Thu, Dec 22, 2016 at 3:37 PM, Nathaniel Manista 
wrote:

> On Wed, Dec 21, 2016 at 2:30 PM,  wrote:
>
>> In our app we need to accept a (large) Grpc message, extract a field, and
>> then based on the value of that field forward the message on to another
>> server.
>>
>> I'm trying to avoid the overhead of completely deserializing the message
>> before passing it on.
>>
>> One way to do this in a microservices environment would be to send the
>> field as a separate query or header parameter, but Grpc doesn't support
>> them.
>>
>> Another way would be to extract just the field of interest from the
>> payload, but Protobuf doesn't support partial or selective deserialization.
>>
>> How else can I do this?
>>
>
> In what programming language(s) are you working with gRPC?
> -Nathaniel
>



-- 
Chris Cleveland
Dieselpoint, Inc.
http://dieselpoint.com
312-339-2677 mobile

-- 
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/CABSN6VfdE9TXfT55fsmukKd4Z834h7g0myLxpZ%2Bn%3DY8OPhLFEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] [Java] A backward-incompatible bugfix in the generated code

['Kun Zhang' via grpc.io]

We just found out bindService() on the generated server interface is 
supposed to be "final", but is currently not.

For example:

public abstract class RouteGuideImplBase {
  // Empty implementations, to be overridden by the application
  public StreamObserver routeSingle(StreamObserver) {
failWithUnimplemented();
  }
  public StreamObserver routeMultiple(StreamObserver) {
failWithUnimplemented();
  }

  // Glue code called by gRPC server to register the service.
  // Not supposed to be overridden.
  public *bindService*() {
...
  }
}

*Why is it an issue*

The non-final bindService() adds difficulty for users who want to mock the 
server interface in their tests. Mockito by default overrides all non-final 
methods with its no-op and null-returning impl. When a Mockito user creates 
a mock for RouteGuideImplBase, it can't be correctly registered to the 
server. It can be worked around by explicitly telling Mockito to use the 
original bindService(), but it's still a friction in the user experience.

*What should we do*

bindService() should have been defined as "final" in the first place. It 
was an oversight that we didn't make it so.  This should be considered as a 
bug (filed as #2552 ) and be 
fixed.

We will make the change in master, which will be in 1.1.0.

*Risk*

This is technically an incompatible API change. Anyone overrides 
bindService() on the generated interface will be broken. However, I don't 
find anyone doing so in google3, or any legitimate reason for it in 
general. The chance of breaking anyone should very low. *If you have any 
concerns, feel free to reply to this thread.*

-- 
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/459fd639-27a9-4dca-9df3-86d8294fb37e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC Java v1.0.3 released

['Eric Anderson' via grpc.io]

The v1.0.3 release has a small bugfix and experimental support for forward
proxies. Only users of InProcess transport in tests or users wanting to
test the forward proxy support benefit from the update.

   - Remove a usage of an executor which was just to avoid lock ordering
   issues. Now the work is done on the same thread, but after locks are
   released. This fixes non-determinism when "connecting" with the InProcess
   transport (#2444 )


   - Add experimental support for http forward proxies via CONNECT to both
   Netty and OkHttp transports. Proxy authentication is unsupported. To
   enable, use the GRPC_PROXY_EXP environment variable and set to a
   host:port-formatted string. Error handling is known to be weak when
   negotiating with the proxy; most proxy failures will result in a generic
   error. Errors after negotiation completes are unaffected.

Although the release does not yet show up in search.maven.org nor the index
pages of the mirrors, it is already available on Maven Central for your use.

-- 
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/CA%2B4M1oPY5kG9sJZQuDK-Vvxvht1AmV2HmpY5P2syeB21tFagfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Avoiding deserialization

['Nathaniel Manista' via grpc.io]

On Wed, Dec 21, 2016 at 2:30 PM,  wrote:

> In our app we need to accept a (large) Grpc message, extract a field, and
> then based on the value of that field forward the message on to another
> server.
>
> I'm trying to avoid the overhead of completely deserializing the message
> before passing it on.
>
> One way to do this in a microservices environment would be to send the
> field as a separate query or header parameter, but Grpc doesn't support
> them.
>
> Another way would be to extract just the field of interest from the
> payload, but Protobuf doesn't support partial or selective deserialization.
>
> How else can I do this?
>

In what programming language(s) are you working with gRPC?
-Nathaniel

-- 
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/CAEOYnAQh%3D-b3EyVY-Pa_USF3%2BNKkQTHHtVMcaYgNeSVrVEzsMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Avoiding deserialization

['Makarand Dharmapurikar' via grpc.io]

"One way to do this in a microservices environment would be to send the
field as a separate query or header parameter, but Grpc doesn't support
them." - gRPC does support custom headers.

On Wed, Dec 21, 2016 at 2:30 PM,  wrote:

> In our app we need to accept a (large) Grpc message, extract a field, and
> then based on the value of that field forward the message on to another
> server.
>
> I'm trying to avoid the overhead of completely deserializing the message
> before passing it on.
>
> One way to do this in a microservices environment would be to send the
> field as a separate query or header parameter, but Grpc doesn't support
> them.
>
> Another way would be to extract just the field of interest from the
> payload, but Protobuf doesn't support partial or selective deserialization.
>
> How else can I do this?
>
>
>
> --
> 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/4181d2cf-2bda-4f9d-8b08-abb177855323%40googlegroups.com
> 
> .
> 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.
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/CALCUQvjcv%2BYGDPXSw%2BJuV6JTctpCo9VwO7Wwg88z%2BKraciZrsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] grpc-java: support graceful server shutdown

['Makarand Dharmapurikar' via grpc.io]

Both Java and C based clients will respect GOAWAY frames, in that a GOAWAY
will induce the client to use a different connection for the following
requests. Will defer to others for DNS resolver interaction.

On Thu, Dec 22, 2016 at 7:21 AM,  wrote:

> Hello,
>
> When we redeploy our servers on AWS, behind an ELB we would like to
> support graceful shutdown by pushing a GOAWAY frame to the already
> connected clients and initiate a graceful shutdown of the clients
> connection to the server. After some amount of time after the GOAWAY frame
> has prompted shutdown we would like the clients to re-establish a
> connection with the servers.
>
> I see this sort of behaviour implemented in the GO server
> https://github.com/grpc/grpc-go/pull/774
>
> Is this also implemented in the grpc-java server (a link to the code would
> be appreciated) ?
>
> Also, we plan to implement a scheduled DNS name resolver for updating our
> ELB DNS with the appropriate TTL https://github.com/grpc/grpc-
> java/issues/2514 , will the GOAWAY frame behaviour above effect a
> scheduled DNS name resolver?
>
> Thanks,
>
> Mike
>
> --
> 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/58f821f2-6b8a-4a8b-b20b-a2d744179627%40googlegroups.com
> 
> .
> 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.
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/CALCUQvgbf1RH%2B6rpc4%3Dpu%3Dnr-Wh_tCP3DwzZSg3Ce%3DHBSy3oeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] what API to get bytes data back

[song1219]

I defined a simple message below
message MfStream {
  bytes message=1;
}

After calling msg.set_message(), code shown below, I serialized msg and 
noticed the msg have two more bytes than the (buf and len). What is the API 
I can use to serialize to the original buf and len? Look forward to your 
reply. Thanks.


char* buf;
int len;
...
...
MfStream msg;
msg.set_message(buf, len);


-- 
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/686ec9fa-c6f0-4f11-9562-b4182f38cc36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] How to reproduce the latency and qps benchmark numbers for grpc-java?

[arufa . hc]

Hi!

The benchmark page shows that grpc-java has a unary call latency of ~300us 
and a qps of ~150k between 2 8-cores VMs.

https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5712453606309888

How do I reproduce these numbers with AsyncClient and AsyncServer? What are 
the command line parameters used for producing these numbers?

I ranthe benchmark on a pair of 16-cores VMs with 40 Gbps network in the 
same datacenter. 

I ran server with:
java io.grpc.benchmarks.qps.AsyncServer --address=0.0.0.0:9000 
--transport=netty_nio

and client with:
java io.grpc.benchmarks.qps.AsyncClient --address=server:9000 
--transport=netty_nio

and results:

Channels:   4

Outstanding RPCs per Channel:   10

Server Payload Size:0

Client Payload Size:0

50%ile Latency (in micros): *2151*

90%ile Latency (in micros): 8087

95%ile Latency (in micros): 10607

99%ile Latency (in micros): 17711

99.9%ile Latency (in micros):   39359

Maximum Latency (in micros):413951

QPS:*10917*


For optimizing latency I ran server with --directexecutor and client with 
--channels=1 --outstanding_rpcs=1

Channels:   1

Outstanding RPCs per Channel:   1

Server Payload Size:0

Client Payload Size:0

50%ile Latency (in micros): *617*

90%ile Latency (in micros): 1011

95%ile Latency (in micros): 2025

99%ile Latency (in micros): 7659

99.9%ile Latency (in micros):   18255

Maximum Latency (in micros):125567

QPS:1094


For optimizing throughput I ran client with --directexecutor and 
--channels=32 and --outstanding_rpcs=1000

Channels:   32

Outstanding RPCs per Channel:   1000

Server Payload Size:0

Client Payload Size:0

50%ile Latency (in micros): 167935

90%ile Latency (in micros): 520447

95%ile Latency (in micros): 652799

99%ile Latency (in micros): 1368063

99.9%ile Latency (in micros):   2390015

Maximum Latency (in micros):3741695

QPS:120428


Without --directexecutor in the server and client with --channels=32 and 
--outstanding_rpcs=1000

Channels:   32

Outstanding RPCs per Channel:   1000

Server Payload Size:0

Client Payload Size:0

50%ile Latency (in micros): 347135

90%ile Latency (in micros): 1097727

95%ile Latency (in micros): 1499135

99%ile Latency (in micros): 2330623

99.9%ile Latency (in micros):   3735551

Maximum Latency (in micros):6463487

QPS:55969


What is the recommended configuration to achieve the claimed throughput of 
150k qps? What are the parameters used for generating the numbers? I'm not 
able to find that anywhere.


Thanks!


Alpha

-- 
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/a3f2110e-e36a-4950-bf94-30a8f4d059e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] grpc-java: support graceful server shutdown

[michael . wright]

Hello,

When we redeploy our servers on AWS, behind an ELB we would like to support 
graceful shutdown by pushing a GOAWAY frame to the already connected 
clients and initiate a graceful shutdown of the clients connection to the 
server. After some amount of time after the GOAWAY frame has prompted 
shutdown we would like the clients to re-establish a connection with the 
servers. 

I see this sort of behaviour implemented in the GO server 
https://github.com/grpc/grpc-go/pull/774

Is this also implemented in the grpc-java server (a link to the code would 
be appreciated) ?

Also, we plan to implement a scheduled DNS name resolver for updating our 
ELB DNS with the appropriate TTL 
https://github.com/grpc/grpc-java/issues/2514 , will the GOAWAY frame 
behaviour above effect a scheduled DNS name resolver?

Thanks,

Mike

-- 
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/58f821f2-6b8a-4a8b-b20b-a2d744179627%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] grpc-java: Jetty ALPN/NPN has not been properly configured

[Jorg Heymans]

Hi,

I have been troubleshooting the ALPN error i was getting under a vanilla 
spring-boot configuration, using 
netty-tcnative-boringssl-static:1.1.33.Fork24 and a plain serverbuilder 
with useTransportSecurity. 

It turns out that it was caused by the spring-boot-starter-web dependency, 
which brings its own version of tomcat-embed-core containing the jni 
classes that are also packaged in the tcnative jar. 

See also https://github.com/netty/netty-tcnative/issues/214 


Jorg

-- 
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/dfda6653-86c2-484f-9eb0-31e8d4a44744%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] [grpc-java] Lots of Stream Error messages while doing Server-side streaming RPC

[Ankur Chauhan]

I am building a grpc server that queries Google cloud bigtable and based on 
a user request and delivers a stream of de-serialized (protobuf) rows to 
the user.

I have noticed that there are a lot of "Stream Error" messages in logs:

"Stream Error
io.netty.handler.codec.http2.Http2Exception$StreamException: Stream closed 
before write could take place
at 
io.netty.handler.codec.http2.Http2Exception.streamError(Http2Exception.java:147)
at 
io.netty.handler.codec.http2.DefaultHttp2RemoteFlowController$FlowState.cancel(DefaultHttp2RemoteFlowController.java:487)
at 
io.netty.handler.codec.http2.DefaultHttp2RemoteFlowController$FlowState.cancel(DefaultHttp2RemoteFlowController.java:468)
at 
io.netty.handler.codec.http2.DefaultHttp2RemoteFlowController$1.onStreamClosed(DefaultHttp2RemoteFlowController.java:103)
at 
io.netty.handler.codec.http2.DefaultHttp2Connection.notifyClosed(DefaultHttp2Connection.java:343)
at 
io.netty.handler.codec.http2.DefaultHttp2Connection$ActiveStreams.removeFromActiveStreams(DefaultHttp2Connection.java:1168)
at 
io.netty.handler.codec.http2.DefaultHttp2Connection$ActiveStreams.deactivate(DefaultHttp2Connection.java:1116)
at 
io.netty.handler.codec.http2.DefaultHttp2Connection$DefaultStream.close(DefaultHttp2Connection.java:522)
at 
io.netty.handler.codec.http2.DefaultHttp2Connection.close(DefaultHttp2Connection.java:149)
at 
io.netty.handler.codec.http2.Http2ConnectionHandler$BaseDecoder.channelInactive(Http2ConnectionHandler.java:181)
at 
io.netty.handler.codec.http2.Http2ConnectionHandler.channelInactive(Http2ConnectionHandler.java:374)
at 
io.grpc.netty.NettyServerHandler.channelInactive(NettyServerHandler.java:274)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:256)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:235)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:360)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:325)
at 
io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:726)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:256)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:235)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1329)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:256)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:242)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:908)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:744)
at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:418)
at 
io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:312)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:873)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:745)


My method is pretty basic and the following snippet captures the essence of 
the service call.

final Stream rowStream = streamFromBigTable(request);
final ServerCallStreamObserver responseObserver = 
(ServerCallStreamObserver) _responseObserver;
StreamObservers.copyWithFlowControl(rowStream.iterator(), responseObserver);

Can someone elaborate on the origin on these error messages? They seem bad 
but I can't seem to find how to control them.

-- Ankur Chauhan

-- 
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/3cfd7a7a-ebb9-4731-93ec-fd7d3294a745%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.