I am implementing standard request/response scenario with MT and RabbitMQ. Client is Asp.net core API and consumer is a windows service.
As part of testing the exception cases if I stop the consumer and submit a request from API using request client, since there is no consumer processing, API got request timeout exception which is cool. But the message is sitting in the consumer queue and when I start the consumer, it picks the message and process the stuff( sending the message to external endpoint) and moved to a _skipped queue as there is no request client listening for this message.
Do you think it is correct behavior? First place when the api got request timeout exception, he will retry anyway so what’s the point of processing first message still?
How can I ignore those message where request clients were already finished processing with any error?
Thanks
What you are describing is very common, and I'd recommend reading up on idempotence and other distributed system failure scenarios.
Sending commands (the request, in this case) and conveying outcomes via a timeout in a message-based system can be very misleading. For instance, if you look at the ForkJoint, in the event of a request timeout, the response is actually a 202/Accepted instead of communicating an error.
The message is in the queue, it will be processed, so there is no reason to fail the controller and report an error back to the caller. So an intermediate response is used instead.
The sample is part of MassTransit Season 3 where I discuss a new idiom to deal with eventual completion/failure of commands in distributed systems. There might be some useful examples in there to help you understand the failure scenarios.
As doc sayed, to discard skipped messages so they are not moved to the _skipped queue:
cfg.ReceiveEndpoint("input-queue", ec =>
{
ec.DiscardSkippedMessages();
});
Related
I thought using RPC is bad practice but all the resources I am finding point to using RPC in order to get a response from a queue after publishing a request. Are there any other ways of doing it? Is it the best practice?
Thanks
MassTransit has built-in support for producing requests (which can be published, or sent directly to a specific endpoint). The request client can be created manually or added to a dependency injection container, and one or more response types can be handled.
MassTransit uses the bus endpoint to receive responses by default.
To register the request client in the container, the AddRequestClient method is used as shown below.
services.AddMassTransit(x =>
{
// configure transport/host/etc.
x.AddRequestClient<CheckOrderStatus>();
});
RPC is a common pattern, and producing requests when a response is required, it a regularly used approach. Another option is combining a command with an event, and observing the event separate from the request producer. However, if a linear programmatic flow is required, using RPC via the request client is an easy solution.
We have two applications (client and server) on the same machine that communicate via a WCF service using named pipes.
The issue that we're seeing is that occasionally a request from the client to the server will time out. WCF tracing is enabled on both ends, and on the server side we see the request being processed and responded to immediately as expected. However on the client side we don't see the response and the request times out after 1 minute.
What's suspicious is that almost immediately after the timeout, the client-side WCF trace shows the server's response arriving, almost as if it had been stuck somewhere and the timeout exception caused it to come un-stuck.
Attached are some screenshots from the client trace of the activity that relates to a particular message. Notice that the message gets sent out at 13:26:31.38, it times out at 13:27:31.80, and then the response gets received at 13:27:31.215.
Has anyone ever seen this behavior with WCF named pipes, where messages responses randomly seem to get stuck?
I have a requirement where in (RabbitMQ)server sends the request to the client and client executes the operation and sends the response back to the server.
I would like to know which mechanism to use for this Topic, PubSub, Routing...
Can we create the bi-directional connection like server-client similar to xmpp in rabbit mq, if yes how can we do?
thanks
Lokesh
You can use a Spring AMQP asynchronous consumer with a MessageListenerAdapter to invoke a POJO. See the reference documentation.
If you want more control; use a simple MessageListener and send the reply with a RabbitTemplate.
This test case shows an end-to-end configuration (client side and server side). The client side automatically takes care of setting the correlationId.
How can I build a synchronous WCF service that wraps asynchronous MSMQ communications?
Let us have a simple scenario. I have a client which supports only synchronous web service calls. I need to send a synchronous request for "Order", but the back end system exposes this as an asynchronous request and response MSMQs. The WCF does not need to have any logic just wrap the MSMQ asych communication and pass parameters back and forth.
Grateful for your help
Let us have a simple scenario. I have a client which supports only synchronous web service calls
Synchronous call means you are using same link (end point url) or channel for your communication between client and server, so according to your assumption no.
Reason: Every time your client will send a request, it will keep waiting for response from server and will produce error.
Alternatively,You can define two services (different end point url) in your wsdl or webservice, one for request and one for response.
At client side you need to invoke these end point url saperately for sending request and receiving response,so it will appear as synchronous but ultimately it will be asynch. Thats all you can do in this scenario.
As per my understanding.
I have a wcf service and handle a lot of client (server document generation). This service should receive a lot of request and should be handle in queue. It also have a callback. (callback will return successfully generated document). I am still using PIA and will implement OpenXML in the future.
Is it wcf msmq is the way to implement this?
Is there any samples might be related? Previously its running in local machine but now want to change it as a so called "Server generated"
WCF MSMQ doesn't support callback directly - it supports only one-way operations. But for example this article discuss how to add this support. With default configuration you can send message back to original sender but it is not a callback. To support responses every client will have to expose queue and pass address of its queue as part of the request to be able to receive the message from the service. More about responses in MSMQ is in MSDN magazine.