I am using MSMQ in WCF services. I am facing one issue in MSMQ, MSMQ stops processing messages from a queue after some time of intervals. I have to make a request to WCF service(.svc file) to start MSMQ. After requesting svc file MSMQ start processing messages from the queue.
I don't know exactly when MSMQ stop processing but, it stops after some time. Do I want to know why MSMQ goes in idle state? How can I resolve this issue?
Related
My requirement is not to consume the messages by the consumer if the condition not met, post the consumed message back to rabbitmq and stop the Masstransit bus (I believe consumer can't be stopped). I can post the consumed message back to rabbitmq and stop the bus but the problem is, as soon as I post the message back, my consumer consumes the same message again before stopping the bus and post the same message back again and it repeats until bus is stopped. In result, I'm getting duplicate messages on the queue.
if(!valid)
{
await ep.Send(message);
bus.StopAsync();
}
I think enabling rabbitmq_message_deduplication plugin may help in this situation but just wonder if there is any other ways to achieve.
I have a wcf service with msmq binding. WCF service process messages receives from MSMQ queue. I am using transactions in client and wcf both. I am having a issue that even after successful processing of the queue message, the message is not deleting from queue and same messages is again received by the wcf service. So one single message is received more then once and processed.
Please help me why the message is coming more then one time even after successful processing. Is there any settings that I need to done at service side?
I just want to find out if this is possible or whether I'm over complicating it.
I have a web application (Let's call it central) that needs to interact with a WCF service that's running on multiple workstations. i.e. The user will select the workstations to send messages to and the web application will need to do a call to each of the workstations. These workstations won't be online all the time and in the worst case there can be just over 600 workstations that messages will need to be sent to at a single time.
I'm thinking of having a separate WCF service running on the central machine that will function as a sort of "proxy" between the web app (central) and the workstations. The web app will then make a single call to this service with a list of messages, the service will then process this list and add the messages to a queue.
From what I've read so far, the workstations will need to poll this central queue for messages but this seems like it will increase overhead quite a bit. Is it possible to push the messages down to the workstation as they are added to the queue?
I've never used MSMQ before and I'm fairly new to WCF as well so if there's a simpler way of achieving this do tell.
I'm thinking of having a separate WCF service running on the central machine that will function as a sort of "proxy" between the web app (central) and the workstations
I don't see any problem with you using an additional service to act as a "proxy".
the workstations will need to poll this central queue for messages
I would probably advise that you have a central "inbox" of messages to process on the central server. The "proxy" then locally processes the inbox. Have the web site send the jobs to the proxy.
Push model
For the workstations, rather than having them read from the server, have the server send the messages to the workstations. Have a unique queue for each workstation and that queue be situated on the workstation itself. Have the service send the message targeted for the workstation to the workstation's queue. As each message from the central queue/inbox is processed by the proxy, the proxy removes said message from the queue and moves onto the next one.
MSMQ Performance
Generally in MSMQ it's better to do network writes than network reads for scaling reasons. A multitude of computers all reading from the same queue is hurtful to performance. In other words, have the "central" service write to the remote queues (MSMQ will take care of transmitting the message when the machine is available).
the workstations will need to poll this central queue for messages but this seems like it will increase overhead quite a bit
Correct. Use BeginRead. Polling is hurtful to CPU and/or a waste of a good thread.
What is the best way to implement in service bus messages that are requiring once a week or once a day etc.
I am thinking of having a separate windows service that just drops in messages from the database into the service bus but is there another way?
In simple terms i want a message that once it is processed, it will appear again in the queue in a specified amount of time to be processed again.Obviously once i process a message i can tell service bus to delete the message or appear again in the queue.
You will need to have some external process (e.g. your windows service) which sends the message in the first place, on schedule. You can use Azure Scheduler to do that, see http://www.prasadthinks.com/blog/2015/07/11/azure-scheduler-can-post-to-azure-service-bus-queue-and-topic/
When you are processing your message, you can do what you are describing i.e. re-send a copy of the message, using BrokeredMessage.ScheduledEnqueueTimeUtc property so that it arrives at the time you want. But I wouldn't do that, does not feel right. If you have your external processing already sending messages on schedule, just rely on that 100%.
I have a winforms client application that sends messages to an asp.net web service, I need to be able to queue these messages on the client and then then send them in order, waiting for a response from the webservice before sending the next message.
I did look at some examples of queueing using WCF but they seemed to have the queue on the server and not the client.
Any advice abotu what technology to use and on how to implement a solution would be very much appreciated.
Why wait for the response of the server before sending the next message? there is no good reason to do that. Just mark the messages with a sequence number and process them in order at the server.
MSMQ has a queue both on the client and the server and moves the message when a connection is available.
There's also good ol' MSMQ, but that queues things on the server as well.
You could use middleware for the queue (MSMQ etc).
An alternative would be a thread-safe producer/consumer queue at the client. Your "main" code just adds to the queue (ConcurrentQueue in 4.0 might work nicely here, although even in 4.0 I tend to use a utility queue I wrote a while ago instead); and you have a dedicated worker thread that dequeues messages, does the WCF work, and processes the response.
If you need reliable delivery, why not use AMQP with a message broker like RabbitMQ?