RPC pattern of RabbitMq

253 views
Skip to first unread message

Archit Thawaria

unread,
Jul 2, 2019, 1:42:30 AM7/2/19
to rabbitm...@googlegroups.com
Hello Experts,

I was going through RPC pattern of rabbitmq. I have some queries regarding this.
 

1. RPC pattern is synchronous or asynchronous.? At first read it looks to me synchronous because client needs to wait for response. Client will wait for response in reply_to queue so will it be able to do other tasks in the mean time?

My scenario is that I have two services A and B. Service A is a rest service which is receiving multiple calls  in real time through http.
Service A will be client and Service B will be server for rabbitmq use case.
Service A will send message in the queue and Service B will read message from queue.
When Service A will send message in the queue then it will have to wait for response in the reply_to queue. 
During this time If Service A will receive another request then will it possible that Service A will send this request in the rabbitmq.

2. How to handle malicious input case? Lets say if one message is malicious and because of this, one of server got crash. Now because rabbit-mq did not get any acknowledgement so it will send this message to another server. Again this request will crash on this server and will be present in the queue for long time. How to identify such cases and remove such malicious input from queue?

I will be grateful if anybody can reply for above queries.  

Thanks,
Archit




Michael Klishin

unread,
Jul 2, 2019, 2:48:14 AM7/2/19
to rabbitmq-users
The tutorial you are looking at is, well, a tutorial. It demonstrates the idea. Your client doesn't have to wait for a response.
Publishing is entirely asynchronous in all messaging protocols RabbitMQ supports and specifically AMQP 0-9-1.
Publishers are also not aware of consumer operations or deliveries. So it is asynchronous semantically but any
asynchronous operation can be made synchronous by waiting for a response/result/event/etc. That's what this tutorial does
to be simpler and focus on how both sides work in the request/response pattern covered.

HTH.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAFeXzHtaGLWvgPE8iFSCk4Fs2GNO%3DoBozi4Vh0ZGPRiQnQZUOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
MK

Staff Software Engineer, Pivotal/RabbitMQ

Archit Thawaria

unread,
Jul 2, 2019, 4:44:22 AM7/2/19
to rabbitm...@googlegroups.com, mkli...@pivotal.io
Hi Michael,

Thanks for the reply. 

Can you please suggest how to implement async RPC pattern? I am mainly looking for request-response architecture just like RPC and it should be async.

Thanks,
Archit

Michael Klishin

unread,
Jul 2, 2019, 4:50:12 AM7/2/19
to Archit Thawaria, rabbitm...@googlegroups.com
Doing what the tutorial demonstrates without making the client wait for a response should be enough. Pass responses to a Go channel or similar.
--
Staff Software Engineer, Pivotal/RabbitMQ

Archit Thawaria

unread,
Jul 2, 2019, 6:01:14 AM7/2/19
to Michael Klishin, rabbitm...@googlegroups.com
Hi Michael,

Thanks for the reply. 
Please suggest how to handle Question 2. 
2. How to handle malicious input case? Lets say if one message is malicious and because of this, one of server got crash. Now because rabbit-mq did not get any acknowledgement so it will send this message to another server. Again this request will crash on this server and will be present in the queue for long time. How to identify such cases and remove such malicious input from queue?  

Thanks,
Archit

Stuart Johnston

unread,
Jul 2, 2019, 6:50:29 AM7/2/19
to rabbitmq-users
Put a TTL (time To Live) on your messages and a dead letter handler

If you have a malicious  message say longer than 5 minutes on the queue rabbitMQ will move it to a DLQ or just expire the message
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.


--
MK

Staff Software Engineer, Pivotal/RabbitMQ

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.

To post to this group, send email to rabbitm...@googlegroups.com.

Michael Klishin

unread,
Jul 2, 2019, 7:00:32 AM7/2/19
to Archit Thawaria, rabbitmq-users
Poison message handling is a design decision in your applications. I'd say your server should handle every
possible exception and terminate intentionally without requeueing the delivery if it cannot do so, or respond
with a special message that says "I am unable to handle this".

Stuart's suggestion around message TTL is not a bad idea but I'd like to stress the importance of designing your consumers
(the request/reply server specifically in this case) with exceptions, potentially newer/incompatible/unknown data formats and
metrics of such events in mind.

Archit Thawaria

unread,
Jul 4, 2019, 7:06:28 AM7/4/19
to Michael Klishin, rabbitmq-users
Hi,

Does rabbitmq support Retry count of a message on consumer . If not can you please suggest how to implement this?
Look like this is the best way to handle poisoned message.
How to check if a message is a fresh message or redelivered message . I have read that When rabbitmq does not get any awk for a message then queue marks that message redelivery=true.
How to identify redelivery information at client level from message.?

Thanks,
Archit

Michael Klishin

unread,
Jul 4, 2019, 7:11:52 AM7/4/19
to Archit Thawaria, rabbitmq-users
Please stick to one question per thread.

It does for quorum queues in 3.8, which is not GA [1]. DLX and message TTL  in combination can be used to implement something similar in a much less elegant way. It has been discussed on this list before and there is no shortage of blog posts about it on the Interwebs ;)

Reply all
Reply to author
Forward
0 new messages