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
Related
I have an instance of ActiveMQ 5.16.4 running that is using MySQL as a persistent data storage. Recently the MySQL server had some issues, and ActiveMQ lost its connection to MySQL. That caused multiple Spring microservices to throw errors because ActiveMQ wasn't working.
Is it possible to have master/slave ActiveMQ running where master and slave uses separate persistence storage?
I have done some research and found "pure master slave", but it says that it is deprecated and not recommend to use and will be removed in 5.8. It says to use shared storage which I am trying to avoid (cause my problem is what if storage itself is down).
What are my options to keep running ActiveMQ if it loses connection to database?
If you're using ActiveMQ "Classic" (i.e. 5.x) then your only option is to use shared storage between the master and the slave. This could be a shared file system or a relational database. This, of course, is a single point of failure.
However, there are both file system and database technologies that can mitigate this risk. For example you could use a replicated file system (e.g. Ceph or GlusterFS) or a replicated database (e.g. MySQL).
You might also consider using ActiveMQ Artemis (i.e. the next-generation broker from ActiveMQ) which supports replication natively.
Is there any good way to integrate OpenLDAP or ApacheDS servers (or maybe another open-source LDAP server) with JMS to propagate LDAP database modification to another service?
Basically I need to have LDAP server cluster (several instances with master to master replication) and another standalone Java application, connected via a JMS server (e.g. ActiveMQ), so that:
All changes to LDAP data structure are sent to the Java app.
The Java app. can send messages to the LDAP database via JMS server to update LDAP data
I found out that there is a way to set up JMS replication for ApacheDS (https://cwiki.apache.org/DIRxSRVx11/replication-requirements.html#ReplicationRequirements-GeneralRequirements), but I am in doubt whether it will work in case we have a cluster of several ApacheDS masters + one JMS replication node to send all modifications to the cluster.
UPDATE: The page describing JMS replication for ApacheDS turned out to be 5 ears old, so currently the only way of replication in ApacheDS, I know about, is LDAP protocol based replication.
There IDM products that will perform what you are asking about.
I know NetIQs IDM products works well with JMS.
OpenLDAP and ApacheDS have a changeLog that you could use to determine the changes made.
You could then write some code to send the changes to JMS Queue.
I can't speak for ApacheDS, but OpenLDAP already contains a full-blown replication system, with about six different ways to configure it; in other words, you can do it perfectly well, and much more efficiently, without Java and JMS.
I am evaluating using NServiceBus as a SOA mechanism in our product. I'm looking into using the publish/subscribe pattern and my understanding is that the subscription service will store all subscriptions.
Does that mean that if my RavenDB server goes down then my publishers lose the ability to send to subscribers? Or is there a way for the publishers to cache the subscribers it has and if RavenDB were to go down then it would deliver to its known subscribers?
You can run the RavenDB server as a replicated node, to avoid this being a single point of failure.
The general pattern is for an endpoint to have a master node that acts as worker and distributor, and then the master node uses a Raven installation on that same server to store its subscriptions and saga storage.
So, it is a point of failure for that one endpoint, but other endpoints in the distributed system will use the Raven installs on their own servers. Thus, the system is kept distributed and the entire system does not have a single point of failure. RavenDB enables this because it is fairly easy to install it on any server.
Contrast this to SQL Server, which is frequently centralized, scaled up to the max, and even clustered in order to provide high availability. (Read: expensive!)
You can also run RavenDB in a Windows failover cluster where the nodes use a shared SAN for the RavenDB data files. If the active node dies, another takes over. Since the data is stored on the SAN, you shouldn't even notice it except the time it takes to start up the RavenDB windows service on the new node. Check out http://ravendb.net/docs/server/administration/fmc_configuration
This is also the recommended setup for High Availability when running with Distributors. http://docs.particular.net/nservicebus/scalability-and-ha/distributor/
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.
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