Streaming in a different thread

[Vivek M]

Hi,

I am working on implementing a gRPC C++ server.  I have observed whenever there is any gRPC request (streaming or unary), there seems to be a thread created in the stack. And if there are multiple streaming requests, there will be as much threads created and will be alive till streaming is ON.

Now if there are requests coming from different clients for SAME data stream then instead of having multiple copies of data floating around in each of these gRPC threads, I am rather planning to write the data into multiple writer objects (which is unique for each streamig session). And I am planning to do the writes in a different thread which is I/O bound and gets the data from various sources.

I would like to know is there a way we can return the gRPC thread back to the thread pool, but still keep the streaming session live? In the above case, the threads created by the stack will be of no use and is just required to keep the streaming session live and it kinds of eats into system resoruces..

Thanks,
Vivek

[Yang Gao]

With the current API, you can use an async server to achieve this. Otherwise you may want to hack the default thread pool implementation.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6628ec23-6b52-426a-b8ac-222e845852a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vivek M]

Thanks for the reply Yang. Sorry for not being more clear before. I will have to serve mix of unary and streaming calls. And I would like to create a new thread only for a streaming call and not for the unary calls.

Is it possible to have synchronous way of serving unary calls and async way for streaming (my server has to listen on only one port for both these cases)? If so, how do we do that?

Thanks,
Vivek

On Monday, November 30, 2015 at 3:35:24 AM UTC+5:30, Yang Gao wrote:

With the current API, you can use an async server to achieve this. Otherwise you may want to hack the default thread pool implementation.

On Sun, Nov 29, 2015 at 2:35 AM, Vivek M <vive...@gmail.com> wrote:

Hi,

I am working on implementing a gRPC C++ server.  I have observed whenever there is any gRPC request (streaming or unary), there seems to be a thread created in the stack. And if there are multiple streaming requests, there will be as much threads created and will be alive till streaming is ON.

Now if there are requests coming from different clients for SAME data stream then instead of having multiple copies of data floating around in each of these gRPC threads, I am rather planning to write the data into multiple writer objects (which is unique for each streamig session). And I am planning to do the writes in a different thread which is I/O bound and gets the data from various sources.

I would like to know is there a way we can return the gRPC thread back to the thread pool, but still keep the streaming session live? In the above case, the threads created by the stack will be of no use and is just required to keep the streaming session live and it kinds of eats into system resoruces..

Thanks,
Vivek

--
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.

[Craig Tiller]

Currently you'd need to define two services: one for the sync calls, the other for async calls. We'd like to have a way to mix sync and async methods within one service, but haven't gotten the API design right just yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1584bd49-8438-4793-bd5c-7d216f509b4a%40googlegroups.com.

[Vivek M]

Hi Craig,

Thanks for confirming this.

I can think of 2 cases here, which might be useful to add:

  1) Sync mode: I see that after the streaming API returns, the call completion queue is deleted. Instead if there is a way to indicate as part of the return value of the API that the processing is still on, the stack can decide not to delete the queue and whenever the app is done with it or call gets cancelled, Finish (Finish needs to be added for sync calls also, currently it is not there) can be called to delete the completion queue and do other cleanup for the call. With this:
                a) The app need not manage the server queue itself (as in case of async) and can still have more control on the calls. And yes the app needs to be aware of what it is doing as in case of async case.
                b) The app can get the gRPC thread for some pre-processing and stuff (which can be CPU intensive) to create a work item. And once done it can handover the work to a new thread and return from the API.

  2) Mix of sync and async calls under the same service: Not to mention, this will be more useful.

Thanks,
Vivek

[Vivek M]

Hi Craig,

Is there an ETA for this? Should we track it via a GIT issue?

Thanks,
Vivek

[Craig Tiller]

There's no ETA currently. It's a gap we knew was there, but you're the first user to have noticed. Opening up an issue would be great, but I don't see this getting resolved this year.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e75c85a5-a378-4fb3-898d-5c880387ef13%40googlegroups.com.

[Vivek M]

There's no ETA currently. It's a gap we knew was there, but you're the first user to have noticed.

[Vivek] Yup, I had an use case which made me think it will be good to have.

Opening up an issue would be great, but I don't see this getting resolved this year.

[Vivek] I have raised an issue for the same:
https://github.com/grpc/grpc/issues/4285

Thanks,
Vivek

[Vijay Pai]

Just a belated followup to this thread. Issue #4285 was closed and it is now possible to mix sync and async methods within a common service. An example of doing so is in hybrid_end2end_test.cc

Regards,

Vijay