I have created an NServiceBus Distributor and Worker, running on separate machines. When I run the worker, it successfully sends a message to the Distributor (and I can see it processed through the Storage queue) but for some reason an output queue is created on the Distributor called
'DIRECT=TCP:xx.xx.xx.xx\PRIVATE$\order_queue$ when the queue should be called
'DIRECT=OS:WORKERDNSNAME\private$\myqueue'.
Does anyone know why the order_queue$ is being created?
Shameless copy direct from an old post at pg2e.blogspot.co.uk:
Transactional queues over HTTP from private networks
When sending messages to a transactional queue over http/s from a
server without a public ip address the ACK-messages may have a hard
time reaching their destination. This is due to the same cause as in
this post (Basically NATting causing a mismatch with the message destination address).
By default the receipts are sent to the sending computers name, which
of course will not work unless both parties resides on the same
network. To fix this you have to map the receipts to the public address
of the sender. This is done by creating an xml-file (of any name) in
C:\WINDOWS\system32\msmq\mapping with the following content.
<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
<setup>
<LogicalAddress>http://msmq.domain.com/*</LogicalAddress>
<StreamReceiptURL>http://[ADDRESS_TO_SENDER]/msmq/Private$/order_queue$</StreamReceiptURL>
</setup>
<default>http://xxx.xx.xxx.xx/msmq/Private$/order_queue$</default>
</StreamReceiptSetup>
Explanation: All messages sent to any queue at msmq.domain.com will
have their receipts sent to the given StreamReceiptURL. The
order_queue$ queue is used to handle transactional control messages.
I suspect later versions of MSMQ or NServiceBus handle creating this queue automatically without you having to create the XML file yourself.
Related
Can anybody explain the different types of queues provided by MSMQ.
Outgoing, private and system queues , what are the functions of them?
Thanks.
Yash
Private queues are registered on the local computer, not in the directory service, and typically cannot be located by other Message Queuing applications
Private queues are accessible only by Message Queuing applications that know the full path name, the direct format name, or the private format name of the queue
In a domain environment, public queues are queues that are published in Active Directory
A transactional queue is one that only contains transactional messages, which are messages sent within a transaction
http://technet.microsoft.com/en-us/library/cc778799(v=ws.10).aspx
This is my proposed architecture. Process A would create items and add it to a queue A on the local machine and I plan to have multiple instances of windows service( running on different machines) reading from this queue A .Each of these windows service would read a set of messages and then process that batch.
What I want to make sure is that a particular message will not get processed multiple times ( by the different windows service). Does MSMQ by default guarantee single delivery?
Should I make the queue transactional? or would a regular queue suffice.
If you need to make sure that the message is delivered only once, you would want to use a transactional queue. However, when a service reads a message from the queue it is removed from the queue and can only be received once.
I'm using MSMQ to transfer a byte array.
The formatter is a BinaryMessageFormatter.
The destination queue is a private one, and I'm using direct TCP communication.
The destination machine is in a different LAN, I access it by its external IP address.
There's a firewall which routs the incoming TCP communication to the actual destination machine (port forwarding).
So the system's architecture looks like this:
[source machine] --> [destination firewall] --> [destination machine]
I've been using the system for a few months, and all went fine.
Recently we experienced a firewall failure.
Apparently, this caused to data corruption:
While the queue is transactional, and the message, according to MSMQ, was successfully delivered to the destination machine, the message's content was corrupted.
That is, the code for reading the message from the queue raised an exception:
try
{
var message = queue.Receive(readTimeout, transaction);
if (message != null)
{
data = (byte[]) message.Body; // this line raises an exception
return true;
}
}
catch (Exception e)
{
Logger.Error("error reading queue", e);
}
I had to delete a few messages from (top of) the queue, and then the system got back to normal.
My question:
Assuming that it was only the firewall's failure that caused this, and knowing it's a transactional queue, how come the message was considered to be delivered?
Isn't MSMQ executing some kind of a checksum to ensure data integrity on transactional queues?
It currently looks like MSMQ entirely "trusts" the TCP layer when it comes to data integrity and completeness.
This is just a guess, but I think the Distributed Transaction Coordinator (DTC) might have troubles here. As the name implies, the DTC is responsible for handling the transactions that involve multiple system in a network.
What I could imagine in your scenario, is that the transactions cannot be correctly managed over your different LANs.
My suggestion to you is to check the configurations of the involved DTC instances in both networks if there are option to enable the communication between them and/ or research if the firewall needs to be set up for to allow DTC communication.
I would like to translate the concept of JMS topics using HornetQ core API.
The problem i see from my brief examination it would appear the main class JMSServerManagerImpl (from hornetq-jms.jar) uses jndi to coordinate the various collaborators it requires. I would like to avoid jndi as it is not self contained and is a globally shared object which is a problem especially in an osgi environment. One alternative is to copy starting at JMSServerManagerImpl but that seems like a lot of work.
I would rather have a confirmation that my approach to emulating how topics are supported in hornetq is the right way to solve this problem. If anyone has sufficient knowledge perhaps they can comment on what i think is the approach to writing my own emulation of topics using the core api.
ASSUMPTION
if a message consumer fails (via rollback) the container will try deliverying the message to another different consumer for the same topic.
EMULATION
wrap each message that is added for the topic.
sender sends msg w/ an acknowledgement handler set.
the wrapper for (1) would rollback after the real listener returns.
the sender then acknowledges delivery
I am assuming after 4 the msg is delivered after being given to all msg receivers. If i have made any mistakes or my assumptions are wrong please comment. Im not sure exactly if this assumption of how acknowledgements work is correct so any pointers would be nice.
If you are trying to figure out how to send a message to multiple consumers using the core API; here is what I recommend
Create queue 1 and bind to address1
Create queue 2 and bind to address1
Make queue N and bind to address 1
Send a message on address1
Start N consumers where each consumer listens on queue 1-N
This way it basically works like a topic.
http://hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA5/user-manual/en/html/using-jms.html
7.5. Directly instantiating JMS Resources without using JNDI
I'm thinking of creating a generic message queue to handle various inter-process messages. (WCF is not an option at this point.) So, rather than have 10-15 different queues for specific messages I'd have 1 queue that is a 'catch-all'.
Obviously sending messages to this queue is a not a problem. Each recipient would listen to the queue for new messages then 'peek' them, but I'm looking for a clean/efficient way to do this. By clean I mean a method that does not require each and every recipient to read the body of each and every message.
Use System.Messaging.Message.AppSpecific (Integer) to specify a recipient.