Re: [grpc-io] Re: gRPC Java 1.14.0 Released

[eleanore . jin]

Hi Eric, 

Thanks a lot, I got it!

On Friday, August 24, 2018 at 3:34:49 PM UTC-7, Eric Anderson wrote:
>
> On Fri, Aug 24, 2018 at 9:05 AM > wrote:
>
>> If I understand you correctly, at certain point in time, there will only 
>> be 1 thread processing the callback, and there will NEVER be multiple 
>> threads processing the callbacks concurrently. 
>> If this is the case, what is the point of having the executor() 
>> configuration in ChannelBuilder and ServerBuilder?
>>
>
> There will only be 1 thread processing *that one RPC's* callback. 
> Multiple threads can be processing callbacks, but for different RPCs.
>
> Also, it's common for applications to already have thread pools sitting 
> around and want to reuse them instead of creating yet-more-threads.
>

-- 
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/bc5f41a8-7d40-41eb-8577-7c3b8522e475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRPC Java 1.14.0 Released

['Eric Anderson' via grpc.io]

On Fri, Aug 24, 2018 at 9:05 AM  wrote:

> If I understand you correctly, at certain point in time, there will only
> be 1 thread processing the callback, and there will NEVER be multiple
> threads processing the callbacks concurrently.
> If this is the case, what is the point of having the executor()
> configuration in ChannelBuilder and ServerBuilder?
>

There will only be 1 thread processing *that one RPC's* callback. Multiple
threads can be processing callbacks, but for different RPCs.

Also, it's common for applications to already have thread pools sitting
around and want to reuse them instead of creating yet-more-threads.

-- 
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%2B4M1oPhEaXK56euVR4H246aOoXE-9F518SCLiioN%2BHTS-ecvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: gRPC Java 1.14.0 Released

[eleanore . jin]

Hi Eric, 

Thanks a lot for the explanation. If I understand you correctly, at certain 
point in time, there will only be 1 thread processing the callback, and 
there will NEVER be multiple threads processing the callbacks concurrently. 
If this is the case, what is the point of having the executor() 
configuration in ChannelBuilder and ServerBuilder? 

Thanks a lot!

On Friday, August 24, 2018 at 7:17:22 AM UTC-7, Eric Anderson wrote:
>
> On Thu, Aug 23, 2018 at 3:00 PM > wrote:
>
>> my grpc client and server are doing bi-directional streaming, in the 
>> StreamObserver.onNext() the client passed to server, its just print out the 
>> response from the server.
>> And on the client side, when creating the channel, I passed a 
>> fixedThreadPool with 5 threads. And I see from client side, the results get 
>> printed by 5 threads.  So that means 5 threads are accessing the same 
>> StreamObserver object, but as you mentioned StreamObserver is not thread 
>> safe?
>>
>> Since the onNext() is just System.out.println(), maybe the threads do not 
>> access the StreamObserver concurrently. but what if the logic of process 
>> the response takes time, and when thread1 hasn't finished with its onNext() 
>> call, the next response arrives, and another thread trying to process it, 
>> is there any consequence of this scenario?
>>
>
> We make sure to call it only from one thread at a time. We'll continue 
> re-using a thread for delivering callbacks if more work is coming. But if 
> there's a period of no callbacks we'll return from the thread. The next 
> time we need to do callbacks a different thread may be chosen.
>

-- 
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/1acaf215-f36d-4eaa-9ebb-bbed32034126%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRPC Java 1.14.0 Released

['Eric Anderson' via grpc.io]

On Thu, Aug 23, 2018 at 3:00 PM  wrote:

> my grpc client and server are doing bi-directional streaming, in the
> StreamObserver.onNext() the client passed to server, its just print out the
> response from the server.
> And on the client side, when creating the channel, I passed a
> fixedThreadPool with 5 threads. And I see from client side, the results get
> printed by 5 threads.  So that means 5 threads are accessing the same
> StreamObserver object, but as you mentioned StreamObserver is not thread
> safe?
>
> Since the onNext() is just System.out.println(), maybe the threads do not
> access the StreamObserver concurrently. but what if the logic of process
> the response takes time, and when thread1 hasn't finished with its onNext()
> call, the next response arrives, and another thread trying to process it,
> is there any consequence of this scenario?
>

We make sure to call it only from one thread at a time. We'll continue
re-using a thread for delivering callbacks if more work is coming. But if
there's a period of no callbacks we'll return from the thread. The next
time we need to do callbacks a different thread may be chosen.

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


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: gRPC Java 1.14.0 Released

[eleanore . jin]

Hi Carl, 

Thanks for the reply! I have a question regarding this:

my grpc client and server are doing bi-directional streaming, in the 
StreamObserver.onNext() the client passed to server, its just print out the 
response from the server.
And on the client side, when creating the channel, I passed a 
fixedThreadPool with 5 threads. And I see from client side, the results get 
printed by 5 threads.  So that means 5 threads are accessing the same 
StreamObserver object, but as you mentioned StreamObserver is not thread 
safe?

Since the onNext() is just System.out.println(), maybe the threads do not 
access the StreamObserver concurrently. but what if the logic of process 
the response takes time, and when thread1 hasn't finished with its onNext() 
call, the next response arrives, and another thread trying to process it, 
is there any consequence of this scenario?

Thanks a lot!

On Thursday, August 23, 2018 at 2:38:07 PM UTC-7, Carl Mastrangelo wrote:
>
> You can see the change here: 
> https://github.com/grpc/grpc-java/commit/defb955f3ab233e11d960a42495ca955306d57a4
>   
> .  StreamObserver wraps a ClientCall.
> On Thursday, August 23, 2018 at 1:09:55 PM UTC-7, eleano...@gmail.com 
> wrote:
>>
>> Hi Carl, 
>>
>> what about StreamObserver thread safety? can you please point to me the 
>> documentation if it exists?
>>
>> Thanks a lot!
>>
>> On Tuesday, July 31, 2018 at 11:18:59 AM UTC-7, Carl Mastrangelo wrote:
>>>
>>> Notice: This is expected to be the last version supporting Java 6. 
>>> Comment on #3961  if 
>>> this causes you trouble. Android API level 14 support will be unchanged.
>>> Dependencies
>>>
>>>- Updated to Netty 4.1.27 and Netty TCNative 2.0.12
>>>- gRPC is now regularly tested with JDK 9 and 10
>>>
>>> API Changes
>>>
>>>- OkHttpChannelBuilder#negotiationType is now deprecated
>>>- Made protobuf, protobuf-lite, and protobuf-nano classes final.
>>>
>>> New Features
>>>
>>>- Channel Tracing now record State Changes
>>>- Stubs now have an RpcMethod annotation for use with annotation 
>>>processors
>>>- Added support for providing List to 
>>>LoadBalancer Subchannels, in addition to the option of providing a 
>>>EquivalentAddressGroup (EAG). This prevents the need for LoadBalancers 
>>>to "flatten" a List into a single 
>>>EquivalentAddressGroup which loses/confuses the EAG's Attributes. 
>>>NameResolvers can now specify Attributes in an EAG and expect that 
>>>the values are passed to gRPC's core. Future work will add List
>>> for OobChannels.
>>>- InProcessSocketAddress now has a useful toString() method
>>>- AndroidChannelBuilder is now easier to build
>>>- RoundRobinLoadBalancer now scales better when using stickiness
>>>
>>> Behavior Changes
>>>
>>>- gRPCLB no longer depends on having a Service Config
>>>
>>> Bug Fixes
>>>
>>>- Fix regression that broke Java 9 ALPN support. This fixes the 
>>>error "SunJSSE selected, but Jetty NPN/ALPN unavailable" (#4620 
>>>)
>>>- Fixed a bug with gRPC LB parsing SRV DNS records ( 6dbe392 
>>>
>>> 
>>> )
>>>- enterIdle() will exit idle mode if channel is still in use (#4665 
>>>)
>>>- TransmitStatusRuntimeExceptionInterceptor now avoids accidentally 
>>>double closing the call.
>>>
>>> Documentation
>>>
>>>- Clarified StreamObserver interaction with thread safety
>>>
>>> Thanks to all our Contributors:
>>>
>>>- @DmPanov 
>>>- @groakley  - Grant Oakley
>>>- @jbingham-google  - Jonathan 
>>>Bingham
>>>- @jyane  - Shohei Kamimori
>>>- @kay  - Doug Lawrie
>>>- @marcoferrer  - Marco Ferrer
>>>- @njhill  - Nick Hill
>>>- @PunKeel  - Maxime Guerreiro
>>>- @songya  - Yang Song
>>>- @sullis 
>>>- @werkt  - George Gensure
>>>
>>>
>>>
>>> See https://github.com/grpc/grpc-java/releases/tag/v1.14.0 
>>>
>>

-- 
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/526c6862-e948-4a81-81d1-e44e39cbefaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRPC Java 1.14.0 Released

['Carl Mastrangelo' via grpc.io]

You can see the change 
here: 
https://github.com/grpc/grpc-java/commit/defb955f3ab233e11d960a42495ca955306d57a4
  
.  StreamObserver wraps a ClientCall.
On Thursday, August 23, 2018 at 1:09:55 PM UTC-7, eleano...@gmail.com wrote:
>
> Hi Carl, 
>
> what about StreamObserver thread safety? can you please point to me the 
> documentation if it exists?
>
> Thanks a lot!
>
> On Tuesday, July 31, 2018 at 11:18:59 AM UTC-7, Carl Mastrangelo wrote:
>>
>> Notice: This is expected to be the last version supporting Java 6. 
>> Comment on #3961  if this 
>> causes you trouble. Android API level 14 support will be unchanged.
>> Dependencies
>>
>>- Updated to Netty 4.1.27 and Netty TCNative 2.0.12
>>- gRPC is now regularly tested with JDK 9 and 10
>>
>> API Changes
>>
>>- OkHttpChannelBuilder#negotiationType is now deprecated
>>- Made protobuf, protobuf-lite, and protobuf-nano classes final.
>>
>> New Features
>>
>>- Channel Tracing now record State Changes
>>- Stubs now have an RpcMethod annotation for use with annotation 
>>processors
>>- Added support for providing List to 
>>LoadBalancer Subchannels, in addition to the option of providing a 
>>EquivalentAddressGroup (EAG). This prevents the need for LoadBalancers 
>>to "flatten" a List into a single 
>>EquivalentAddressGroup which loses/confuses the EAG's Attributes. 
>>NameResolvers can now specify Attributes in an EAG and expect that 
>>the values are passed to gRPC's core. Future work will add List
>> for OobChannels.
>>- InProcessSocketAddress now has a useful toString() method
>>- AndroidChannelBuilder is now easier to build
>>- RoundRobinLoadBalancer now scales better when using stickiness
>>
>> Behavior Changes
>>
>>- gRPCLB no longer depends on having a Service Config
>>
>> Bug Fixes
>>
>>- Fix regression that broke Java 9 ALPN support. This fixes the error 
>>"SunJSSE selected, but Jetty NPN/ALPN unavailable" (#4620 
>>)
>>- Fixed a bug with gRPC LB parsing SRV DNS records ( 6dbe392 
>>
>> 
>> )
>>- enterIdle() will exit idle mode if channel is still in use (#4665 
>>)
>>- TransmitStatusRuntimeExceptionInterceptor now avoids accidentally 
>>double closing the call.
>>
>> Documentation
>>
>>- Clarified StreamObserver interaction with thread safety
>>
>> Thanks to all our Contributors:
>>
>>- @DmPanov 
>>- @groakley  - Grant Oakley
>>- @jbingham-google  - Jonathan 
>>Bingham
>>- @jyane  - Shohei Kamimori
>>- @kay  - Doug Lawrie
>>- @marcoferrer  - Marco Ferrer
>>- @njhill  - Nick Hill
>>- @PunKeel  - Maxime Guerreiro
>>- @songya  - Yang Song
>>- @sullis 
>>- @werkt  - George Gensure
>>
>>
>>
>> See https://github.com/grpc/grpc-java/releases/tag/v1.14.0 
>>
>

-- 
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/9cb7b4e0-530f-4ee9-abbc-f26bc17fd2f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRPC Java 1.14.0 Released

[eleanore . jin]

Hi Carl, 

what about StreamObserver thread safety? can you please point to me the 
documentation if it exists?

Thanks a lot!

On Tuesday, July 31, 2018 at 11:18:59 AM UTC-7, Carl Mastrangelo wrote:
>
> Notice: This is expected to be the last version supporting Java 6. Comment 
> on #3961  if this causes 
> you trouble. Android API level 14 support will be unchanged.Dependencies
>
>- Updated to Netty 4.1.27 and Netty TCNative 2.0.12
>- gRPC is now regularly tested with JDK 9 and 10
>
> API Changes
>
>- OkHttpChannelBuilder#negotiationType is now deprecated
>- Made protobuf, protobuf-lite, and protobuf-nano classes final.
>
> New Features
>
>- Channel Tracing now record State Changes
>- Stubs now have an RpcMethod annotation for use with annotation 
>processors
>- Added support for providing List to 
>LoadBalancer Subchannels, in addition to the option of providing a 
>EquivalentAddressGroup (EAG). This prevents the need for LoadBalancers 
>to "flatten" a List into a single 
>EquivalentAddressGroup which loses/confuses the EAG's Attributes. 
>NameResolvers can now specify Attributes in an EAG and expect that the 
>values are passed to gRPC's core. Future work will add List for 
>OobChannels.
>- InProcessSocketAddress now has a useful toString() method
>- AndroidChannelBuilder is now easier to build
>- RoundRobinLoadBalancer now scales better when using stickiness
>
> Behavior Changes
>
>- gRPCLB no longer depends on having a Service Config
>
> Bug Fixes
>
>- Fix regression that broke Java 9 ALPN support. This fixes the error 
>"SunJSSE selected, but Jetty NPN/ALPN unavailable" (#4620 
>)
>- Fixed a bug with gRPC LB parsing SRV DNS records ( 6dbe392 
>
> 
> )
>- enterIdle() will exit idle mode if channel is still in use (#4665 
>)
>- TransmitStatusRuntimeExceptionInterceptor now avoids accidentally 
>double closing the call.
>
> Documentation
>
>- Clarified StreamObserver interaction with thread safety
>
> Thanks to all our Contributors:
>
>- @DmPanov 
>- @groakley  - Grant Oakley
>- @jbingham-google  - Jonathan 
>Bingham
>- @jyane  - Shohei Kamimori
>- @kay  - Doug Lawrie
>- @marcoferrer  - Marco Ferrer
>- @njhill  - Nick Hill
>- @PunKeel  - Maxime Guerreiro
>- @songya  - Yang Song
>- @sullis 
>- @werkt  - George Gensure
>
>
>
> See https://github.com/grpc/grpc-java/releases/tag/v1.14.0 
>

-- 
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/66a396b7-b427-48f1-870c-076a59961a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.