SimonCropp
commented
11 years ago Raised by @yvesgoeleven
The ReplyTo address works as expected, azure serivcebus has no concept of machines, it's a centralized service (your queue sits somewhere, but not on a known server). The part after the @ identifies the service in this case.
From the looks of the stacktrace, a message is being sent during the commit of the local transaction, it's probably one that has logically been sent before either by the user's code, or by NServiceBus internally
yvesgoeleven
Raised by @CallumHibbert Migrated from by https://github.com/Particular/NServiceBus/issues/1449
When hosting on premise with "AzureServiceBus" transport, the "ReplyTo" address does not appear to be set correctly.
NSB v4.0.2
When receiving a command from the queue, the handler throws the following exception:
2013-08-16 09:22:13,537 [16] INFO NServiceBus.Unicast.Transport.TransportReceiver [(null)] <(null)> - Failed to process message NServiceBus.Unicast.Queuing.QueueNotFoundException: Exception of type 'NServiceBus.Unicast.Queuing.QueueNotFoundException' was thrown. at NServiceBus.Unicast.Queuing.Azure.ServiceBus.AzureServiceBusMessageQueueSender.Send(TransportMessage message, QueueClient sender, Address address) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\azure\NServiceBus.Azure\Transports\ServiceBus\AzureServiceBusMessageQueueSender.cs:line 79 at NServiceBus.Unicast.Queuing.Azure.ServiceBus.SendResourceManager.Commit(Enlistment enlistment) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\azure\NServiceBus.Azure\Transports\ServiceBus\SendResourceManager.cs:line 23 at System.Transactions.VolatileEnlistmentCommitting.EnterState(InternalEnlistment enlistment) at System.Transactions.TransactionStateCommitted.EnterState(InternalTransaction tx) at System.Transactions.PreparingEnlistment.Prepared() at System.Transactions.VolatileEnlistmentPreparing.EnterState(InternalEnlistment enlistment) at System.Transactions.TransactionStateVolatilePhase1.EnterState(InternalTransaction tx) at System.Transactions.CommittableTransaction.Commit() at System.Transactions.TransactionScope.InternalDispose() at System.Transactions.TransactionScope.Dispose() at NServiceBus.Unicast.Transport.TransportReceiver.TryProcess(TransportMessage message) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\Transport\TransportReceiver.cs:line 238 at NServiceBus.Unicast.Queuing.Azure.ServiceBus.AzureServiceBusDequeueStrategy.TryProcessMessage(Object obj) in c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\azure\NServiceBus.Azure\Transports\ServiceBus\AzureServiceBusDequeueStrategy.cs:line 150
I am not at all sure where the "QueueNotFoundException" is coming from - the handler has received the message. Debugging and looking at the stack trace, the problem seems to arise after the handler logic is run and when NSB is trying to de-queue the message.
The only thing I can think is that the command has an odd Reply To address. The address is of the form "queue@server" and not of the form "queue@Endpoint=sb://myNamespace.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=mySharedSecretValue" as I would expect for an Azure Service Bus message. However, I am not explicitly trying to reply to the command in my code so don't really see how this matters.
More info: "http://tech.groups.yahoo.com/group/nservicebus/message/20211"