This is rather a stupid question. But I couldn't find a good post regarding this.I want to create a queue in Outgoing queue in MSMQ.
I have a task to get all the Outgoing queues in the machine and clear the messages if it matches to a criteria.
Can anybody give an idea how to create an Outgoing queue in Windows server 2008 machine.
You don't "create" an outgoing queue.
When you send a message to a queue the MSMQ sub-system first writes the message to a local, temporary, outgoing queue before transmitting the message to the destination queue. The lifespan of the temporary outgoing queue is controlled by the MSMQ sub-system and not the developer.
This is because MSMQ uses a store and forward model to transmit messages around.
John Breakwell talks about this here.
However, you can address the outgoing queues in the same way you would address the remote queue which you are sending to, but setting a flag called MQ_ADMIN_ACCESS.
This technique is described here.
Related
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.
I came across a situation in my work environment. where i have wcf service which receives messages from client and store in db. Now my problem is suppose server was down for 10 mins these 10 mins messages should be stored in client at some place and client should check for availability of server for every 1 min.Is there any procedure that i could follow or any help would be appreciated .Thank you
binding :netTCPBinding
MSMQ does exactly what your first sentence says - when you send an MSMQ message, if it can't get the remote queue then it stays with the client and the built-in MSMQ service retries in the background. That way your message, once sent, is "safe." It's going to reach its destination if at all possible. (If you have a massive message volume and messages need to be stored for a long time then storage capacity can be an issue, but that's very, very unlikely.)
Configure WCF to send/receive MSMQ messages
I'd only do this if it's necessary. It involves modifying both the service and the client, and the documentation isn't too friendly.
Here's the documentation for MsmqBinding. Steps 3 and 4 for configuring the WCF service are blank. That's not helpful! When I selected the .NET 4.0 documentation those details are filled in.
I looked at several tutorials, and if I was going to look at this I'd start with this one. I find that a lot of tutorials muddy concepts by explaining too many things at once and including unnecessary information about other parts of the writers' projects.
The client queues its messages locally
If you don't to make lots of modifications to your service to support MsmqBinding. You could just implement the queuing locally. If the WCF service is down, the client puts the message in a local MSMQ queue and then at intervals reads the messages back from that queue and tries sending to the WCF service again. (If the WCF service is still down, put the message back in the queue.)
I'd just send messages straight to the queue and have another process dequeue and send to WCF. That way the client itself just "fires and forgets" if that's okay.
That way you don't have to deal with the hassle of modifying your service, but you still get the benefit. If your message can't go to the WCF service then it goes someplace "safe" where it can even survive the client app terminating or the computer restarting.
Sending and receiving messages in a local queue is much easier to configure. Your client can check to see if the queues exist and create them if needed. This is much easier to work with and the code samples are much more complete and on-point.
I'd like to get your ideas as to how I can make my service process scale horizontally by being able to run it across multiple servers. It is a Windows service written in C#, and its purpose in life is to subscribe to our company's Exchange Web Service (EWS) so that it gets notified (via HTTP callback) whenever there's a new incoming email message. The service then gets the email message, processes it, sends a reply if possible, then goes back to sleep and waits for the next incoming email.
If I run it on more than one machine, I can either have all of them subscribing to EWS notification, or only one of them. If I have all of them subscribe, I am kind of hesitant because it might add burden to our MS Exchange infrastructure. Also this will result in all machines receiving and processing the email. I wouldn't want the sender to receive a reply N times (where N is the number of servers in the farm) for a given request message! Now if I have only one machine subscribing to EWS, that exposes me to a single point of failure.
I'd like to get your suggestions on how to address this. I'd love to have multiple servers process incoming messages by distributing email messages among them (perhaps I'll have to do this by making use of a message queueing server). Thanks.
Depends if you are scaling for reliability or throughput.
If reliability, you can have a primary and a standby process. The primary process subscribes and processes all emails. The standby process exchanges keep-alive messages with the primary and takes over as primary if the keep-alive times out.
If throughput, then a message queue mechanism , as you suggested, may be a good approach. You could run primary and standby as above, but the primary just pulls emails into a queue. A farm of message processors pulls off the queue.
I am new to MSMQ . We have a situation where we have many c# applications(.exe) sending data packets on a port. They can send the data packets to a port . How can I configure MSMQ to automatically read from the port and post these data packets to MSMQ. We cannot afford to loose any of these data packets and so loss of data is not acceptable at all . How can this be done efficiently. Can MSMQ be configured to accept the data packets from port 1801 . If these applications we have wrote to different ports will that be better ? Are if they wrote to one port , how can these messages be sent to the MSMQ directly with NO DATA LOSS.
We want the queue to be transactional. We dont want to use the data packets that arrive.
Please help . Any sample code which can do this task will be of great help.
Please NOTE that the applications are written in C# .NEt. Data loss and slow performance has been a problem and we are trying to solve them using MSMQ. We must see all data packets from these applications in MSMQ.
Thanks
How can I configure MSMQ to automatically read from the port
unless you are prepared to write code I don't think this is possible. So on the assumption that you don't mind a little bit of code for yourself, check out the System.Messaging.Message class. The Body property allows you to send in a byte array.
So provided you are reading from the port into some kind of byte array, putting it into a message should be a doddle.
How can this be done efficiently. Can MSMQ be configured to accept the
data packets from port 1801.
If these applications we have wrote to different ports will that be
better?
1801 is already the default port for MSMQ TCP packets, see MSDN article TCP ports, UDP ports, and RPC ports that are used by Message Queuing.
If your port numbers are indeed important, you may configure the WCF service to listen on certain ports in its address part of the service configuration.
When working with MSMQ you normally do not have to deal with any special ports, except when configuring communication between multiple networks through firewalls (MSDN Article: How To Configure a Firewall for MSMQ Access ).
If possible, I would recommend to stick with the default values.
How can these messages be sent to the MSMQ directly with NO DATA LOSS.
We want the queue to be transactional.
If you use transactional queues you secure the message automatically against data loss. More on this in Queuing in WCF and Reliable Messaging with MSMQ and .NET
Data loss and slow performance has been a problem and we are trying to
solve them using MSMQ. We must see all data packets from these
applications in MSMQ.
MSMQ itself is fast and lightweight, but as with every other tool, it all depends on what you do with it - and how. If you start sending large data packets, MSMQ might get into trouble, too. Keep in mind that MSMQ has some limitations, e.g. for message size.
Here are articles/ tutorials to get you started with WCF in combination with MSMQ:
MSDN: MSMQ and WCF: Getting Started
Message Queuing to Windows Communication Foundation
A more complete scenario with secured communation: Creating a WCF Service with MSMQ Communication and Certificate
Security (Code Project)
I have one MSMQ-WCF service that is creating a queue and maintains the MSMQ queue service.
Also, I have another WCF Services hosted in WAS, working like a Listener.
As soon as a message arrives in the MSMQ Queue, it should be automatically picked from the queue and the message should be read.
I just wanted to use it MSMQ Listener adapter. Is there any other way to do this? Please let me know.
It's much simpler to host the queue listener in a windows service. This way there is no need to involve WAS and all the complicated setup that can involve.