Wednesday, May 19, 2010 9:26 AM
I am sending single message to my msmq using MCS proxy client.But instead of sending one its sending two messages to msmq.One actual message and one small message.I am not getting why its sending two message.
Any body have any idea.
Wednesday, May 19, 2010 7:53 PM
When using the MCS proxy with load-balancing and failover, by default the generated proxy sends a 'ping' message (typically isOnline) prior to sending your actual message--so this is why you see this. If the ping fails, then a new node is selected, (and this is pinged again to ensure online). Hence if you have multiple nodes processing incoming messages (no matter the binding, including msmq bindings) this ping message is received for every service op call. While this does add a small bit of overhead, the advantage is per-request failover between load-balanced nodes and better scale-out characteristics. You can also choose not to do such a ping by specifying 'none' for the Online Request Method when setting up your connected service on the client side. Load balancing will still be in effect, but no ping is sent and it would then be up to you to decide what to do if the service request fails.
Friday, June 11, 2010 11:18 AM
Will you please give us details about setting none parameter.
e.g. From where we need to set this? through code or using configweb url.
Also if possible provide some sample code having this property set to none.
Thursday, June 17, 2010 5:46 PMModerator
No code required, you can use ConfigWeb. You want to do this from the client side configuration service. For example, for StockTrader, you would login to the Business Services config service using ConfigWeb. On the home page of ConfigWeb, choose Remote Services. Find the connected service description you want to change, and select it (in this case the MSMQ Transacted Queue). You will be on a page called "Manage Connected Services" with the details for the connected service subscription you want to alter. It turns out, you need to blank out the field for "Online Check Method". Do not type in "None"; rather just make sure it is a completely blank field (no spaces even); changing it from "isOnline". Then click the update button.
Note, from this point on, in the Connections Tab you will see the connections to the remote MSMQ WCF Service; but the server icons will be grey---meaning no online check is being performed anymore from the client.
The isOnline check method/message will still be sent when looking at SOAMAP or the "View Defined Nodes" link in ConfigWeb. The difference is that here, the server itself is sending the null test message (not the client). The results are then sent back up to the client. If you do not want the server cluster to be able to send a null (isOnline) test message to its own nodes either; then you would login to the Config Service of the MSMQ-bound service itself; and bring up "Hosted Services"; select the service endpoint, and null out the "Online Check Method" here as well.
But if you do just for the client, your business logic will no longer send null test messages to the queue, load balancing will still work; but up to you to handle failover conditions should a node be crashed (meaning, the MSMQ NT Service is stopped on one or more nodes).
Greg Leake, Microsoft
Tuesday, June 22, 2010 6:27 AMModerator
Also note, beginning with MSMQ 4.0 (which first shipped with Windows Vista/Win Server 2008; and later in Win 7 and Win Server 2008 R2); there are some good options for handling unprocessed messages to a dead-letter queue; which could be periodically auto-purged, for example. Basically, if on Windows Server 2003, there are some key features you are missing that are available with Win Server 2008 (first edition or R2; as well as Vista and Win 7); that allow you to do some more advanced and automatic handling of unprocessed messages.
Perhaps not obvious to me in the StockTrader sample app; how null isOnline messages are interrupting your WCF-MSMQ-bound service host from working over time. Let me know. In the StockTrader sample, since must work on MSQM 3.5 (as well as 4.0); a custom error behavior is configured to ship bad messages to an exception queue; and get out of the mainstream queue. However, the simple void/isOnline 'ping' messages do not invoke this logic or interfere with mainstream queue processing, in all my testing.
Greg Leake, Microsoft
Monday, August 30, 2010 7:15 AM
We have suppressed this online check by using ConfigWeb url. However i would like to know how do we handle these ping messages manually.
I mean you have stated in your earlier post that "Load balancing will still be in effect, but no ping is sent and it would then be up to you to decide what to do if the service request fails."
How do we decide and handle the service requests that are not processed or what we do if one of the node is not working due to which messages should not get lost.
Do let us know is there any code change required to handle this issue?
Thursday, September 02, 2010 6:33 PMModerator
When using WCF over MSMQ, your contract is "one way" meaning fire and forget. Unlike a non-MSMQ bound MSMQ service, the requirement on the server is that the MSMQ messaging service (an NT Service) is running, not that the WCF host program itself is running. First, you want to ensure you are using a durable (transacted) queue. This means messages are persisted to the server's disk, not stored in MSMQ in-memory cache. So if using a transacted queue on each server, even if your WCF host is not running, as long as MSMQ message service is running, messages will be received and persisted to disk. The next time your WCF host program starts (if it was not running for awhile while messages were being sent from client), it will process messages in order from each MSMQ.
If on any host, your MSMQ message service is not running (machine down, network down, MSMQ service stopped, etc), your *client* program will get an exception. Even though its fire and forget, the client still will throw an exception when trying to send the message to a non-existent (downed) MSMQ message service. At this point, your client program needs to decide what to do, based on your desired business logic. If you are using Config Service for load balancing (or other load balance mechanism like hardware/software load balancing against multiple MSMQ hosts), you might simply delay/re-try the send to the same host. You might simply display an exception to the user, saying try again later. Or you might attempt the send again to a new host if available per below.
With Config Service load balancing *without* the isOnline ping (default), you can use the Client API (see Config Service Technical Guide installed in start menu) or the client constructor with bool set to 'create new client instance' to create a new client instance one or more times, and each new client instance will be against a new load balanced node if there are multiple nodes running. The client API also lets you simply retrieve a list of available nodes. Without the ping enabled, this list will be all possible nodes, whether online or not, however. But at this point you have a list of available URIs, and you can use the generated client constructor with the address'es to manually cycle through all known hosts before displaying 'try again' exception to user. If all MSMQ message services are down, of course, all client attempt to write to MSMQ will fail. But key is, the client is getting that exception so you can handle as you want.
Greg Leake, Microsoft