MSMQ messages stuck in ‘outgoing queues’

[David Mäder]

Helpful information to include

Product name: NServiceBus

Version:4.7.8

I’ve found various posts on this, but none of them enabled me to get my problem resolved.

My service receives a message and sends back an acknowledge message, by using Bus.Reply() method.

I tested this with a message sender and a self-hosted service that receives the message, both running on the same machine, and it works fine. If, however, the message sender and the service are on separate machines, the acknowledge message gets stuck in the outgoing queue.

I noticed that the queue name in ‘Outgoing Queues’ reads: DIRECT=OS:S5038789VM05DEV\private$\cs.isr.whitelabeling.bus – not a fully qualified domain name! So that probably explains.

 

I checked the following things:

- On Message Queueing Properties, in Server Security tab: un-checked “disable un-authenticated RPC calls”, but this didn’t help.

- Ping: only works if I provide the full NetBIOS and domain name, NetBIOS name alone doesn’t work. I added the NetBIOS name to the lmhosts.sam file, but to no avail. Plus there are suggestions not to use that file in a production environment, as it seems to be some outdated way of handling networking (e.g. the IP address may change)

- DTCPing: same story here, I couldn’t get it to work, the hostname could not be resolved

 

One suggestion was to use message mutators. But the convenient thing about the Reply() method is that I don’t have to know where the message is coming from, and I really don’t want to know it! We’re in a dynamic environment, where configuring and syncing host names would be a nightmare. So if I mutate the message, I’m back to needing to know the specifics of the remote host. And isn’t the whole “ServiceBus” idea to loosely couple systems? If I can’t do that I always have be aware of every participating system’s whereabouts, constantly synching my configuration.

 

I have no idea what else to do to enable message sending. Is there anything in addition I need to configure? Or is it a problem to use the “Reply” method in the first place?

Any ideas or hints are welcome. Many thanks – David

[Bruno Bertechini]

Ping by host name only should work. I guess it's related to networking.

Have you configured the servers nic to have a dns suffix?

Bruno

Sent from my Samsung device

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at https://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/a79382c7-1528-44eb-ad0b-1e2e9c3b5218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Mäder]

"Ping by hostname should work" - I disagree. That's where the LMHOSTS.SAM file comes in, if I have a mapping in there, then yes, it should work. But as I say, we don't want to go down that route in a production environment. To me it's totally understandable that the message cannot be sent without a FQDN. The question really is: Why doesn't "Bus.Reply()" use the FQDN, since it knows where the message initially came from? Or, is there a way I can enforce that behaviour? To me this seems a really basic feature, I don't understand why that's not happening per default.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.

[Indu Alagarsamy @ Particular.net]

Hi,

Can you please check if you have this patch?

https://support.microsoft.com/en-us/kb/2554746

Thanks,

Indu Alagarsamy

Particular Software

[David Mäder]

I haven't got that patch, but according to the description I run the command "netstat -ano | findstr 1801" to check whether this issue has occurred. My result suggests it hasn't, so I suppose I don't need the patch.

To me it looks as if NSB doesn't use the domain; e.g. I also tried "Bus.Send(Bus.CurrentMessageContext.ReplyToAddress, msg)", but the ReplyToAddress seems to know the Machine name only, without domain.

[Jan Ove Skogheim]

David,

If you want NServiceBus to use FQDM on ReplyToAddress, you need to override how NServiceBus resolves the local machine name. The default is to use Environment.MachineName. Provide a factory method through RuntimeEnvironment.MachineNameAction that gets the local machine name in a FQDM format and NServiceBus will use that. http://stackoverflow.com/questions/804700/how-to-find-fqdn-of-local-machine-in-c-net provides a good starting point on how to get the FQDM of the local machine.

Remember that as soon as you start using FQDM you probably want to do the same for message mappings and any direct queue destinations you provide to Bus.Send().

Regards,
Jan Ove Skogheim
Particular Software

[David Mäder]

Hi Jan - thank you for the hint. If I understand you correctly, the proposed approach relies on the message sender to make sure the FQDN is incorporated in the message. Unfortunately I have no control over message sending, as these are coming from another system.

In the meantime, however, I have some evidence suggesting this might be a Windows environment issue. I've tested my service on another machine (different version of Windows) where it worked as expected. So I'm currently investigating if the hotfix mentioned earlier (KB 2554746) can resolve the issue. I'll keep you posted. Many thanks, David

[David Mäder]

Ok, I can confirm KB 2554746 has resolved the issue. Many Thanks, David

[Indu Alagarsamy @ Particular.net]

David,

Thanks for letting us know. 

Cheers,

Indu Alagarsamy

Particular Software