I want to handle a situation in RabbitMQ RPC when a client is disconnected that way: server checks that response queue exists and if it doesn't - cancel current task.
So I have few questions:
does this solution look good? (i have some undescribable doubts about that)
what is the way to perform this check? (i found only able to check response queue existence via RabbitMQ HTTP API)
Related
I have configured MassTransit with RabbitMQ as transport. And I just use an instance of generic IRequestClient to send requests to a consumer that then should return a response.
My problem is that every other request fails with a TimeoutException. Execute it once, the next time it fails, and then it works again.
The Consumer is not even invoked when failed.
What can be the reason for this?
I have other services share a similar name in their requests and consumers. I have tried to figure out if that is the problem.
You should post the configuration code of your application using the request client and the one configuring the consumer.
If you have other consumers with the same name, it's likely they're on the same queue if you're using ConfigureEndpoints, which could be the root cause of the issue.
Since it's every-other-message that times out, that would make sense since RabbitMQ will load balance the queue across the different services with the same queue name.
I'm currently running microservices in my company. They are not api servers, just processes that communicate with each other. So the implementation to communicate with each other is RabbitMQ.
Now I'm trying to implement a health checker to know if a server has restarted or crashed.
But I'm only familiar using a health check by calling a specific api in the server. But our services aren't an api server so they don't have any ports to imply. And I also don't wan't to add an api server for just to implement a health checker.
So I'm searching about any use cases about implementing health checks by sending messages (health check signals) to the health checker by a message broker such as RabbitMQ instead of using APIs.
Does anyone have some ideas?
Sounds like an obvious and easy mechanism for a system like yours that already relies on message queuing. Implement any architecture you want from publishing specific messages to each service - either on a single exchange where every service (as client) looks for himself as the topic, or on an exchange-per-service - or you could simply have an exchange that's read from by the health-check service and all services emit messages periodically (dead man style) to that exchange - and that service just makes sure it hears from anyone once in awhile.
Consider also using rabbit event exchange at your health-check service - so it'll be able to keep track of service connect/disconnects from the channel the service is talking to the exchange with. Channels are suppose to stay up all the time, so a disconnect indicates trouble of some kind - especially if it wasn't preceded by a service (as client) sent message indicating a normal going-down event. In other words, as a health "protocol" - instead of getting polled by a health service, each microservice would be proactive about sending "coming up", "ready", "healthy" (periodically), and "going down" messages to the health service.
As a general comment: In my opinion message queues are very much underutilized. There are many use cases they're more appropriate for than other techniques (e.g., more popular techniques like REST over HTTP). They provide distinct benefits which are built-in to the message queuing/message broker concept which you might very well otherwise need to provide for yourself for your use case (or use a "framework" which has provided it). I'd always consider the role - all the roles! - of a message broker in a system architecture and use it where it fits.
Hi i'm really new to RabbitMQ. I want implement the RPC pattern but with multiple clients and one server. Can anyone recommend a responsive way of implementing this. I'm a bit concerned the code I have implementing one client and one server will introduce blocking issues, ideally I'd like the client to get a response fairly quickly.
First just to get terminology straight:
in RMQ context, RMQ is a broker (server) whose clients are producers and consumers.
in RPC context (and in example on the tutorial) we have a RPC client(s) and a RPC server(s). So when we "map"this to RMQ context, we say that RPC client is actually both RMQ producer and RMQ consumer (because it sends the request and receives a reply) and that RPC server is both RMQ consumer and RMQ producer (because it waits for requests and then sends a reply)
Now, if you implement it the same way that's done in the tutorial (aforementioned link), you won't have any problems. You should simply start more RPC servers, so that more requests may be handled in parallel.
I have experienced the following situation with an ActiveMQ Pub/Sub implementation. If the connection to the message broker is lost the publisher could re-try to establish a connection since the publish method would throw an exception.
However if the connection to the message broker is lost at the subscriber end, the subscriber would not know it. This would be the same if the session expires.
Proposed solution:
One of the solutions I thought was to implement a heartbeat at the subscriber end to periodically publish a ping message to a separate topic so that the subscriber could know if the connection is dropped. This works fine, but the down side is that the amount of ping messages generated by the subscribers available in the system. The second option I thought was to implement the heartbeat to try and create a connection in an interval. WDYT?
Do you see a better way of implementing this? Appreciate your thoughts.
Use the ActiveMQ Failover transport and don't disable the inactivity monitor and the client will check the connection and automatically reconnect as needed. Without more information on you set-up that's about the best answer.
We are using MSMQ right now with WCF activation feature, it enables us not to pull queue to read messages. It like push message to application.
As we are looking at porting from MSMQ to RabbitMQ going through what we need from message queue.
I can't anything regarding RabbitMQ .net client support for receiving message notification from subscribed queue?
Is there anything in RabbitMQ with .net which can do push notification to subscriber like MSMQ?
Or we need service running which constantly checks for message?
In AMQP (and RabbitMQ), there are two ways to retrieve messages: basic.get and basic.consume.
Basic.get is used to poll the server for a message. If one exists, it is returned to the client. If not, a get-empty is returned (the .NET method returns null).
Basic.consume sets the consumer for the queue. The broker pushes messages to the consumer as they arrive. You can either derive DefaultBasicConsumer, which gives you your own custom consumer, or you can use the Subscription Message Pattern, which gives you a blocking nextDelivery().
For more information, check out the API guide linked above and the .NET Client Userguide. Also, a great place to ask RabbitMQ-related questions is the rabbitmq-discuss mailing list.
I think you are after something like the EventingBasicConsumer. See also this question/answer
That is a feature provided by WAS (Windows Activation Service). Right now WAS has listener adapters for net.pipe, net.msmq and net.tcp (and its port sharing service). I guess you would need a specific AMQP listener adapter.
This may help http://msdn.microsoft.com/en-us/library/ms789006.aspx