I have an application written in Python (PIKA) and C# (official NuGet package). Those applications are publishing new messages into RabbitMQ queues.
Until now, I used this syntax to publish a new message into the queue:
model.BasicPublish(exchange, routingKey, basicProperties, body);
I found that BasicPublish function always returns with success. I also read in RabbitMQ documentation that in case of broker destroyed, the messages that didn't send yet will be removed without sending it to RabbitMQ.
I want to avoid the loss of messages. So, I found 3 options to submit those messages to publish:
Transaction - Very slow.
Confirmation - I found it tricky to implement in a multi-threaded environment.
with REST API - What do you think about that?
I think that it will be ideal for me yo use REST API for inserting messages into queues.
The Question:
The way that I found to send a message with API is to send POST message to this endpoint:
http://localhost:15672/api/exchanges/vhost/amq.default/publish
As you can see, this port (15672) belongs to the RabbitMQ management system.
Is this the right way to use RabbitMQ with REST API?
Can I trust the RabbitMQ management system in the production environment?
Can you recommend an alternative to REST API that will accept to message enqueue immediately after insertion (blocking)?
No, don't use the HTTP API. It is not intended for production use for publishing or consuming messages.
You must use publisher confirms. The technique described in this tutorial applies to the .NET client library as well.
You could also investigate libraries written on top of the official .NET library that may correctly implement publisher confirms for you. EasyNetQ is one such library.
Another good resource to read with concern to 100% reliability is this blog post.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
Related
I have an older C# app that is being migrated to the cloud. It uses SignalR, but only direct client/server connections. No SignalR service is involved yet.
I am extracting some processes that are well suited for an Azure function, but one feature I would prefer to not have to redesign for this MVP is a SignalR message back to the user that tells them the percent complete for this job.
I am reading the MS documentation from here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-signalr-service-output?tabs=in-process&pivots=programming-language-csharp focusing on Isolated-Processes.
I can see how I can send messages to the Azure SignalR service, but I am unclear how I might be able to just send a message back to the caller.
I would really like to set up a simple Hub and send messages directly to the client as the function progresses.
I would suggest giving web pub sub a look? Microsoft has a good comparison article here. Summary, it is a bit more language agnostic, and if you're already using azure then it has less setup overhead than SignalR.
https://dev.to/albertbennett/how-to-azure-pubsub-service-2ccb
Like the title says.
Is there a way to use gRPC in combination with some kind of message broker/ Queue with .NET?
It does not have to be RabbitMQ. I am open to use alternatives.
\
I want to send messages from 1 client to 2 servers but i need to prevent that the 2 servers process the request at the same time, hence the message queue/broker.
You could do this with Azure Service Bus. Client could be on-premises or in Azure. Same for servers 1 and 2.
Note: You should be able to gRPC to Azure Service Bus, but you may need to use HTTP/REST function for topic/subscription to send messages to Server 1 or 2.
Another approach to consider:
https://grpc.io/blog/grpc-load-balancing/
I think to best answer your question, I assume the reason why you want to use rabbitmq with grpc is because you'd like to have better decoupling from client to servers while still using rpc pattern. With this in mind, this might be something you actually need:
rabbitmq - rpc pattern (could find tutorial from rabbitmq docs)
google protobuf to be your contracts between services
The idea is that client is connected to the queue with two channels, one is to send message where you can specify the destination to be a specific service (in your scenario service1); two is a reply channel where service1 would be sending message back to the client.
Kafka and the confuent platform supports grpc and google proto-buffer as a serialization schema.
I have been looking at whether I can use RabbitMQ to assist in sending bulk emails from a console application (C# ASP.NET CORE).
I have had a good look through their website but can not find a specific tutorial on the use of RabbitMQ for bulk emailing.
https://www.rabbitmq.com/getstarted.html
Can anyone point me in the right direction?
Thank you,
Aaron
From what I've read on their site & comments here it would seem the only sensible implementation might be to use the producer with my loop, then write a consumer that will send the emails and in the case of an application failure this would allow the messages to continue - but this wouldn't give me reports on whether the emails themselves have delivered/failed - nor would it provide robustness for the emailing part (inside the consumer) of the application
This is reasonable enough and yes, you will have to implement parts of this system yourself, and test it to ensure reliability meets your expectations. You should read about these RabbitMQ topics:
Durability
Persistence
Message acknowledgements
Publisher confirms.
You may also be interested in this plugin.
And finally, please only send email to people who want to receive it, and give people an unsubscribe option.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I have been playing around with pubsub and so far it looks good for what I need (a basic game experiment).
From a Javascript perspective and mobile (via Appcelerator's Titanium) I can really see the value of using pubsub.
However, I need to write a server app in c#/.NET (although open to other ideas) to listen to the subscriber queue I have, and process the messages.. which involves some decision making etc, and then possibly writing another message to the publish queue for example.
So far I have played with RX (Reactive Extensions) for C# which listen on my subscribe channel. So far so good, I see the messages come in, although for now I just wrote a C# console app to test.
My question is would the best way to wait and listen for pubsub subscriber messages be to write a windows service app? or is there another technique more appropriate? obviously at some possible point I might have to scale the server to 2-3 servers, however given the nature of pubsub queue/messaging, I don't see a problem if I had some load-balancing etc.
Any ideas welcome!
Use Service Bus. When cloud is good for you, than Azure Service Bus. When not then nServiceBus. Take a look also for RabbitMQ, it's AMQP framework and is able to do more then pubsub. Also rabbit has multiple clients on multiple platorms. For example one of approaches purely for JavaScript is RabitMQ + Node.js + WebSockets.
All clients and devtools, and articles about RabbitMQ for different platforms and languages are here.
There is also special RabbitMQ binding for .NET, find it here.
NServiceBus PubSub explanation is here. It's .NET service bus, but is not such free as RabbitMQ. Anyway RabbitMQ is platform agnostic.
Any of service buses implementations already has PubSub, that is the reason they exist. Therefore there is no reason to implement, what is already implemented
Is it recommended to use NServiceBus (or any service bus library) solely for the purpose of publishing messages on the client side?
I've been looking at a handful of sample open source projects and they all seem to have one thing in common. All projects are publishing messages and getting consumers to handle the specific message (or command).
Essentially, I'm looking to decouple my actions by sending out messages and have a handler take care of it. This would all be done locally on the client.
I think NServiceBus and equivalent tools are too heavy on the client side and often requires extensive configuration.