Thanks Kun for clarifying.
So basically I can use long-lasting stream and push message when they
available as showing in below stock update snippet.
public class StockServiceImpl extends StockServiceGrpc.StockServiceImplBase
{
public void stockUpdate(StockServiceOuterClass.HelloRequest request,
StreamObserver<StockServiceOuterClass.HelloResponse> streamObserver)
{
//run a loop
{
//check if response object can be constructed by checking our DB
//if it can be , then create it and hand it over to the streamObserver
StockServiceOuterClass.HelloResponse response =
StockServiceOuterClass.HelloResponse.newBuilder().setStockInfo(“new data from
DB”).build();
streamObserver.onNext(response);
//but if NO new data available in DB, just sleep for a while like
Thread.sleep(30 sec);
//check again if any data is available in our DB to create a
response object
}
// When you are fully done, you amy call onCompleted.
//technically this line will close the underlying http/2 stream which I would
not do it very quickly
streamObserver.onCompleted();
}
}
On Wednesday, April 17, 2019 at 12:34:58 PM UTC-5, Kun Zhang wrote:
>
> HTTP/2 stream can be opened for a long time and used to push messages when
> they become available.
> If you have L4 load-balancer in front of the server, you may want to
> configure NettyServerBuilder.maxConnectionAge() so that the server will
> tear off connections that have lived for too long, so that the client will
> automatic reconnect and the load-balancer can rebalance the connections to
> servers.
>
> On Monday, April 15, 2019 at 7:24:47 AM UTC-7, chirag shah wrote:
>>
>> Hello
>>
>>
>> As we know, Server-side notification/push can be achieved by multiple
>> ways depending upon what you want to achieve.
>>
>> In my use-case , the built-in HTTP/2 SERVER_PUSH frames based approach
>> is NOT feasible.
>>
>> Another approach is web-socket. But that does not fit very well with
>> HTTP/2
>>
>> Web-push API is also not a good fit because it is based on service-worker
>> and more heavy-weight compared to some in-line technology.
>>
>>
>>
>> In this context, I believe I can do it with HTTP/2 + server-side-event
>> and leverage Event-Source Mechanism.
>>
>>
>>
>> However , I am interested in exploring if some streaming-based gRPC API
>> can help me.
>>
>> Basically, in my use-case I want the server to send the data if/when
>> available with him.
>>
>> So in simple terms
>>
>> I invoke one gRPC server-side streaming API in asynchronous, non-blocking
>> mode and then continue on my client-side browser work.
>>
>> The implementation of gRPC server-side code will just push the data
>> whenever available by calling streamObserver.onNext(response);
>>
>> If data is not available the server-side method will just sleep for a
>> while before checking for the next time.
>>
>> Basically, the underlying design here is the HTTP/2 stream that is
>> spawned will remain open forever on that TCP connection.
>>
>>
>>
>> Do you think this is scalable enterprise level architecture ? Can we
>> keep the HTTP/2 stream open for long time ?
>>
>>
>>
>>
>>
>> Thanks.
>>
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/e81c4684-7f13-4c3a-b5ab-2d606f8616f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
