OkHttpChannelBuilder#negotiationType
is now deprecatedRpcMethod
annotation for use with annotation processorsList<EquivalentAddressGroup>
to LoadBalancer Subchannels, in addition to the option of providing a EquivalentAddressGroup
(EAG). This prevents the need for LoadBalancer
s to "flatten" a List<EquivalentAddressGroup>
into a single EquivalentAddressGroup
which loses/confuses the EAG's Attributes
. NameResolver
s can now specify Attributes
in an EAG and expect that the values are passed to gRPC's core. Future work will add List<EAG>
for OobChannel
s.toString()
methodenterIdle()
will exit idle mode if channel is still in use (#4665)TransmitStatusRuntimeExceptionInterceptor
now avoids accidentally double closing the call.StreamObserver
interaction with thread safetyThanks to all our Contributors:
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?
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?