I'm in the process of updating an existing application that currently can only be deployed on premise, but in the near future we also need to be able to deploy it on Azure. The current implementation uses MSDTC, but this is not supported on Azure. Is it possible to run NServiceBus without MSDTC when deploying it on premise? Or should I enable MSDTC when deploying on premise, but ignore it when deploying on Azure?
Is it even possible to run NServiceBus without MSDTC at all? If I configure NServiceBus like this:
.IsTransactional(false)
it still tries to start a distributed transaction. So I suppose MSDTC is always required?
When you deploy NServiceBus to the cloud there is no MSMQ available for it to use. You can configure it to use Azure Storage Queues.
Because the underlying transport is so different I don't see any advantage disabling transactions in NSB on-premise as any behavior as a result of this may not transfer to the cloud environment.
MSDTC is required by default when using MSMQ. You can avoid DTC if you enable and configure the outbox feature
Related
We are looking at using ActiveMQ as the message transport with NServiceBus, instead of MSMQ, to enable Java endpoints to directly integrate with .NET endpoints over ActiveMQ.
By default NServiceBus endpoints run in a distributed transaction involving MSMQ and SQL Server. Is there the same level of support for distributed transactions in NServiceBus when the message transport is ActiveMQ? Are there any other drawbacks to using ActiveMQ with NServiceBus as compared to MSMQ?
We've actually uncovered issues with the .net client of ActiveMQ - it doesn't support distributed transactions well enough. While we've tried to work with the committers over there, we still haven't been able to get this fully resolved.
At this point in time, if you want to use ActiveMQ on .net (with or without NServiceBus) you'll have to take care of deduplicating any messages flowing through your system.
We're working hard to build this kind of infrastructure-level deduplication logic into NServiceBus such that queues like RabbitMQ and Azure Service Bus that don't support distributed transactions give the same behavior as MSMQ.
From the book Learning NServiceBus by David Boike:
Like MSMQ, ActiveMQ supports the DTC which ensures that our message handlers remain fully transactional.
As far as drawbacks go:
ActiveMQ server does not support DTC transactions for deferred messages.
Other issues are reported on the NServiceBus.ActiveMQ GitHub site. I recommend perusing the list.
I have an IIS/WAS hosted service running as myself in the development environment. It is activated using net.msmq binding. It is configured to use BufferedReceive (it is a WF service), which involves locking the queue. (Sub queues prefixed lock_ are created).
After some time and after the app pool is terminated, the lock queues are automatically removed.
After moving the system to production, with the environment AFAIK identical, but with the service running as a dedicated account, the lock queues are no longer cleaned up. If I stop the app pool, the lock queue remains, with messages.
The most obvious difference is the accounts under which the service runs but I can't find what kind of permissions are affecting this. Alternatively, is there some other configuration difference I am overlooking. Thanks for help.
OK this turns out to be a bug in IIS/WAS.
I had 3 app pools , 2 of which were auto-starting, one of them consuming the msmq. All shared the same AD domain identity, which was shared with the NetMsmqListenerActivator. That netmsmqlistener service was originally stopped, but after I had started it, the symptoms appeared.
Somehow IIS/WAS was creating multiple channels, sending messages to the wrong processes. I have worked around this by creating a separate identity, used now by the mq consuming web service and the netmsmqlistener, followed by a server reboote.
This was a painful problem that only occured on the production server. The lesson learned is to make sure that the production server shares the same hotfixes and patches as the test server .
UPDATE: Hotfix for Win 2k8 R2 SP1: http://support.microsoft.com/kb/2672277
A newbie question : If I am not using Sagas or pub/sub model, do I need any persistence layer with NServiceBus?
The default persistence is RavenDB, I was wondering if I just use NSB without RavenDB or any persistence layer?
Side note:
Currently I have to run RavenDBServer.exe before I can even play around with NserviceBus, so if I do start using NServiceBus, I don't want to have a dependency on another app running in production. This could be a issue with my install.
NServiceBus only uses persistence for storing subscriptions for pub/sub and for saga state. If you aren't using those then you don't need RavenDB or any other implementation. I believe the NServiceBus.Core binary by default comes bundled with RavenDB DLLs, but it won't be needed in production in your case.
If I understand correctly, you could also use the NServiceBus.Lite profile which I believe uses in memory persistence. This is a great way to go as you are developing and trying to learn NServiceBus. However, I'm not sure you'd want to do so in production. It would be a better practice to have some persistence either in a database or file system to ensure reliability of your application in the case of errors or application restarts.
Is there any way to configure second level retries without taking an additional dependency on RavenDB or making database schema changes?
We have an existing system that uses NServiceBus with transactional message queues and are self-hosting NServiceBus in a .NET Windows service.
The second level retries makes use of the timeout management capabilities in NServiceBus, which you can configured to use NHibernate rather than RavenDB as described at the bottom of this page: http://docs.particular.net/nservicebus/nhibernate/
I have an NServiceBus installation (a single server, obviously).
Is it possible to configure the NSB persistence to use a single RavenDB database (not server)?
If so, what would the configuration be?
The scenario I am thinking about is whether it is possible to use RavenHQ so that all my NSB data is backed up off the machine running the bus.
Just use the connectionstring option(NServiceBus.Persistence) and point all your endpoints to the same db. Be aware that you need to use NSB 3.2.3 since the TimeoutManager was patched to support this in that version