grpc calls on activemq

95 views
Skip to first unread message

Karan Kaira

unread,
May 13, 2021, 8:16:37 AM5/13/21
to grpc.io

I am working with ActiveMQ(beginner). I want to put gRPC calls as a message on ActiveMQ. As soon as consumer picks a message , the gRPC in the message should execute.

gRPC calls take parameters , so I want to understand how to send these parameters in the message body along with the method name/identifier , or if there is any another way of achieving this which is followed already?

Example :

```

someResponse response = someStub.rpcMethodName(parameter); // grpc call
```

What I need is to store this statement in some format on activemq without calling the grpc now , then in the future when the consumer of activemq picks up the message containing this statement it should execute this gRPC call.

Thanks.

Sanjay Pujare

unread,
May 13, 2021, 11:55:20 AM5/13/21
to Karan Kaira, grpc.io
Take a look at how gRPC is implemented over http2 at https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md .

That will give you some idea of how you can "persist" the relevant parts of an http2 request as an ActiveMQ message to be executed later as a gRPC call. 

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/dda22bd6-3f96-4a7e-80b6-24a069744f29n%40googlegroups.com.

Amit Saha

unread,
May 13, 2021, 5:28:20 PM5/13/21
to Karan Kaira, grpc.io
If the key objective you are trying to achieve here is to defer the execution of the actual request itself, you may be able to do so by coming up with a way to handle an incoming gRPC call/request, persisting the data in the broker (may be a custom serialisation format? Or may be you could use JSON) and then having consumers consuming from that broker, which recognises the data format, and then makes the actual gRPC call.

Jeff Steger

unread,
May 13, 2021, 7:12:25 PM5/13/21
to grpc.io
Hi all, 

I have a quick question about grpc connections. I am running a grpc synchronous server that mostly replies to single (not streaming) requests with single (not streaming) replies. I understand that each new request is handled by a thread from the grpc framework’s threadpool. I notice that for even after the request is handled and a reply is sent and processed by the client, the tcp connection between the client and server is not taken down. How long does the connection persist? Is it in anyway coupled to the lifetime of the thread in the threadpool? When does the threadpool reclaim the thread that was used to process the request? Thanks for your help!

Jeff

Sanjay Pujare

unread,
May 13, 2021, 7:42:18 PM5/13/21
to Jeff Steger, grpc.io
Comments/questions below:

On Thu, May 13, 2021 at 4:12 PM Jeff Steger <be2...@gmail.com> wrote:
Hi all, 

I have a quick question about grpc connections. I am running a grpc synchronous server that mostly replies to single (not streaming) requests with single (not streaming) replies.

Which language are you using?

I understand that each new request is handled by a thread from the grpc framework’s threadpool. I notice that for even after the request is handled and a reply is sent and processed by the client, the tcp connection between the client and server is not taken down. How long does the connection persist?


"When there has been no RPC activity on a channel for a specified IDLE_TIMEOUT, i.e., no new or pending (active) RPCs for this period, channels that are READY or CONNECTING switch to IDLE. .... We will use a default IDLE_TIMEOUT of 300 seconds (5 minutes)."

Is it in anyway coupled to the lifetime of the thread in the threadpool?

The thread lifetime and connection lifetime should be unrelated.

When does the threadpool reclaim the thread that was used to process the request? Thanks for your help!

Depends on the gRPC language you are using.
 

Jeff

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

Jeff Steger

unread,
May 14, 2021, 12:08:43 AM5/14/21
to Sanjay Pujare, grpc.io

Hi Sanjay,

I am using C++. Does this help you to clarify your below statements?

Jeff


Sanjay Pujare

unread,
May 14, 2021, 1:36:55 AM5/14/21
to Jeff Steger, grpc.io
I'll let someone from the gRPC C++ side answer your questions.

Jeff Steger

unread,
May 17, 2021, 11:39:59 AM5/17/21
to grpc.io
Hi,
I am running a grpc synchronous server impemented in C++. I notice when I run that many threads named ‘default-executo’ are spawned. It seems that even when clients cease to make connections, these threads still persist. There are dozens of these threads, and I would like to know what they are doing and what their lifespan is. Thanks!

Jeff

Mark D. Roth

unread,
May 19, 2021, 1:19:11 PM5/19/21
to grpc.io
The gRPC server synchronous API in C++ has a thread pool to manage polling and request handling.  The thread pool grows and shrinks as needed but always keeps some capacity around for new incoming requests that may show up at any time.  The threads should go away when you shut down the server.

Jeff Steger

unread,
Jan 2, 2022, 11:44:24 AM1/2/22
to Mark D. Roth, grpc.io
grpc-java has a method in its ServerBuilder class to set the Executor. Is there similar functionality for grpc-c++ ? I am running a C++ grpc server and the number of executor threads it spawns is high and seems to never decrease, even when connections stop. 

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

Mark D. Roth

unread,
Jan 4, 2022, 11:54:31 AM1/4/22
to Jeff Steger, grpc.io, AJ Heller
There isn't currently any way to do this.  However, we should probably look at making some changes here once we finish moving to EventEngine, since the polling threads will wind up being decoupled from this thread pool anyway.
--
Mark D. Roth <ro...@google.com>
Software Engineer
Google, Inc.
Reply all
Reply to author
Forward
0 new messages