tag:blogger.com,1999:blog-15136575.post5328880523315539381..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: RabbitMQ Request-Response PatternMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-15136575.post-21617659530195665002017-07-18T20:01:47.596+01:002017-07-18T20:01:47.596+01:00Can someone shed some light on why the response qu...Can someone shed some light on why the response queue is unique to the instance? It is because the assumption here is that the request is stateful? What if I have a pool of workers that watch the response queue and any one of them can process the response? I assume the response queue could then be shared?<br /><br />Thoughts welcome - thx!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-9314019212829266552014-08-09T04:11:37.953+01:002014-08-09T04:11:37.953+01:00Thanks for sharing. Glad to know I'm not the o...Thanks for sharing. Glad to know I'm not the only one wondering which approach to take!<br /><br />I'm trying to avoid RPC as I'm not looking for data, but would like to get a simple job-completion status back, to update an upstream legacy system which originally raised the jobs.<br /><br />From an MQ noob's perspective, it seems a shame you can't send a response code back with the ACK, rather than having to bolt on an entire separate reverse channel.lazykatehttps://www.blogger.com/profile/08433198845453242862noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-57219117290445762442013-10-30T06:36:14.658+00:002013-10-30T06:36:14.658+00:00We are in the process of implementing something si...We are in the process of implementing something similar with the added complexity that the 'client' is a web application that is being polled at regular intervals for new data that can take a significant period to return from the 'server'. In addition, we would like the polling to be load balanced across a pool of stateless web apps. This means we can't really have a long-lived client connection.<br /><br />Our proposed approach is to use a queue per 'user session' (i.e. a sequence of polling requests that are correlated with a single web app user and 1 or more pending request messages) that will auto-delete (x-expires) after a timeout period. This means that client connections can be created and dropped within a polling request and still connect to the same reply queue. Similarly, we can guarantee that the reply queue will be available for the 'server' to publish to for the diuration of the session. We still need to verify with this will work at scale (we estimate that there will be in the region of 1000 active queues at peak load).<br /><br />http://www.rabbitmq.com/ttl.html#queue-ttlAnonymoushttps://www.blogger.com/profile/18058491865113905518noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-8488791332057753062013-10-30T05:11:13.997+00:002013-10-30T05:11:13.997+00:00@Neil
TCP connections are iniated from the client...@Neil<br /><br />TCP connections are iniated from the client side and kept alive. Responses are sent back from the broker on the same connection.<br /><br />This means that you only need a FW rule to allow egress traffic from the client (which often isn't required at all; many systems are setup to allow all egress traffic).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-84165068188809697292013-10-29T16:54:00.651+00:002013-10-29T16:54:00.651+00:00How do you get around the issues of firewalls etc ...How do you get around the issues of firewalls etc for getting messages back to the client? What's the actual transport over t'internet? The main reason Signalr has gained so much traction is because it works over HTTP port 80. To use a queuing system, you have firewalls, external IP addresses vs. internal IP addresses (i.e. port forwarding etc). Do those issues still apply?Neil Barnwellhttps://www.blogger.com/profile/00488709862149357803noreply@blogger.com