How to trigger bidiStream gRPC API to send Message again during a REST API running

Question

hope you are doing well, I have a little question that is hanging me here.

I have an interaction between a REST and a gRPC (bidiStream type) as this: gRPC will call up to initiate a session, then I cast REST one which reponses' will be standing by (roughly, it means loading) until gRPC called up again for it to throw out a response, I have made up a script as this

exec(
    fromClientSide
      .connect
      .header(metadataObject.Authorization)(s"Bearer ${metadataObject.TokenKey}")
      .callOptions(CallOptions.DEFAULT.withDeadlineAfter(30, TimeUnit.SECONDS))
      .endCheck(statusCode is Status.Code.OK)
  )
  .exec(
    fromClientSide
      .send(WarmUp_Msg)
  )
  .pause(200)
  .exec(
    REST_API_HERE
  )
  .during(2){
    exec(
    fromClientSide
      .send(request_Msg)
  )
    .exec(complete)
  }
  .exec(fromClientSide.reconciliate(waitFor = NextMessage))

As I understand the during() in your example, I see that you can trigger chatCall to send a new package, I think I did the same thing, but I'm not sure why the REST API keeps running instead of throwing out the response.

So how do I achieve this kind of interacting between the two?

Answer 1

I have difficulty deciphering your problem description. My guess is that the HTTP call you have will only return after the completion of (or, certain messages in) the stream.

This sounds like a Rube Goldberg machine.

---

In a chain of actions, a virtual user in Gatling completes them one by one. Rewriting your Gatling code in pseudo-code:

grpc_stream = connect()
grpc_stream.send(WarmUp_Msg)
sleep(200)
make_http_call()
t = now()
while now() < t + 2
    grpc_stream.send(request_Msg)
grpc_stream.complete()
reconciliate(grpc_stream)

I hope it is now obvious that line 7 of the pseudo-code won't execute until line 4 is done.

In other words, fromClientSide.send(request_Msg) won't be executed until your REST_API_HERE finishes.

---

In other words, you are looking for a way in Gatling to start an HTTP request without "blocking"¹ the virtual user, which then sends the messages in the gRPC stream.

This is not supported usage.²

You can try to simulate that with two virtual users. One makes the HTTP call, the other makes the streaming gRPC call.

Or better yet, remove the complexity in your backend design.

---

¹ The "non-blocking" aspect of Gatling is that the threads are not blocked by IO.

² I'm not saying it's impossible, just unsupported.