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.
Related
sorry if now I can't provide all the details, but I'm trying to use NServiceBus on Azure Service Bus using the Basic configuration. NServiceBus fails on start because it tries to create a Topic and a Queue, and Basic mode of Azure Service Bus doesn't suport Topics. Any help or workaround? Thanks!
I think you're talking about Basic Tier (pay).
Not with the current version of the ASB transport. Current version of transport only has one topology QueueAndTopicByEndpointTopology which is creating topics by default. You have two options: switch to Paid Tier or implement an alternative topology and use that (not a trivial task). Next version of transport will support more topologies and allow better mechanism to plug custom implementations.
But have you considered the following: without Topics you cannot have pub/sub. This would be a severe limitation when using bus architecture.
As Sean outlined, basic tier is currently not possible out of the box. But I'm curious to know why prefer Basic tier over Storage Queues?
Is not Apache Kafka another implementation of JMS?
I am using JMS+AMQ in my application, and migrating to Apache Kafka. Do I have to change all JMS codes?
No, Kafka is different from JMS systems such as ActiveMQ.
see ActiveMQ vs Apollo vs Kafka
Kafka has less features than ActiveMQ, as the stress has been put on performances. So before migrating, check that the features you use in AMQ are in Kafka.
However, there is an open suggestion for a bridge between JMS and Kafka, to allow exactly what you need. Maybe the provided links can help you
https://issues.apache.org/jira/browse/KAFKA-1995
Actually, the two are not the same. And with a little more time seeing the two co-exist - and listening to problems and happy points from those deploying each in the field - there is a little more to say about each one.
Firstly, JMS supports both point-to-point messaging (where messages are sent to single consumers; the consumers themselves maintain their message queues) and the publish-and-subscribe (pub/sub) model (where messages are written to a single topic, and consumers, independently, decide which messages to consume).
In a point-to-point messaging architecture, message producers and consumers know each other, where as in a pub/sub model they do not. Apache Kafka focuses on a pub/sub model, maintaining a separate log/topic from which consumers read from offsets. Kafka is also built for the cloud, with high-throughput a core consideration.
Many in our community and at meetups throw their hands up in frustration at MOMs (message-oriented middlewares) like JMS and switch to Kafka, for, what boils down to one reason: scalability. They argue that Kafka is better suited for scale than other MOMs because Kafka maintains a partitioned topic log. In so doing, Kafka can split up message flow to groups of consumers by partition and batch transmit the messages.
This concept also allows Kafka to have more granular control over ACLs (access control) to Kafka Consumers, although there are some issues there, which Apache Pulsar is addressing.
Finally, on Kafka, since the client/consumer decides which messages to consume (by offset in the topic), this removes some of the producer-side complexity of routing rules built into MOMs like JMS.
There's more differences than that, but this is a distillation of some of the ones that keep coming up! Hope this helps.
No, Kafka uses its own non-standard protocol and clients.
However, there's a 3rd-party JMS Client for Kafka from Confluent.
We are building Workflow Foundation service with .NET 4.5 and are attempting to use MSMQ to deliver messages that Workflow Service should process.
We have enabled Allow Buffered Receive in order to have messages wait for Workflow to be able to process them.
However, we've ended up with some weird kind of locks in our message folders (see the pictures).
There is no documentation whatsoever to explain this. What is this? Is it related to WF, WCF, MSMQ? Where to look for solution?
I have no idea about the locks but I decided to implement my own queuing solution within my workflow outside of MSMQ due to past issues with MSMQ. I found the following article that helped me implement a queuing solution using SQL Server Implementing Message Queues in Relation Databases
Using a variant of this technique, IIS 7.5 AutoStart, WWF bookmarks and Context Based Correlation I was able to implement a persistent queue within my workflow without using MSMQ. The nature of workflow makes queuing within the workflow very doable.
NServiceBus Distributor/Worker pattern makes perfect sense for MSMQ due to the hard requirement of local input queues.
But this is not the case with RabbitMQ, I am trying to understand how and when the NServiceBus distributor is relevant with RabbitMQ. With RabbitMQ multiple workers can read from the same remote queue.
The actual scenario is similar to using an AWS auto-scaling group to scale out workers pointing to a high available RabbitMQ cluster. Now avoiding distributor altogether makes the setup much simpler to build, test and provision.
Thoughts?
As RabbitMQ transport falls into the broker style bus, so, in your use case, it would make more sense not to use the distributor.
The same goes for all broker-style transports, where you can use a competing consumer pattern to scale out.
NServiceBus is an excellent system and does wonders in most message queuing system where you don't have an integrated distributor (which you do with exchanges in RabbitMQ). We use NServiceBus here at our company.
Azure Queues and MSMQ are perfect examples of such queuing technologies.
NServiceBus handles the distribution internally and therefore reproduces this capability for you.
However... If you are blessed with the possibility of imposing what queuing technology you can use, then I would highly encourage you to look into RabbitMQ and a product (Open Source) called MassTransit
http://masstransit-project.com/
MassTransit can in turn function in the two modes and will either delegate or simulate the distribution for you - however I nonetheless have a soft spot for NServiceBus as do our senior devs here.
Per this page...
http://docs.particular.net/nservicebus/load-balancing-with-the-distributor
Using the distributor is only useful when using MSMQ - if you aren't using MSMQ then there is no point. RabbitMQ and other transport will allow access to the same queue from multiple consumers, while MSMQ will not. The distributor in a nutshell will take messages from the main queue and distribute them across multiple worker queues as they report that they are done with whatever they are working on.
Would someone be able to shed some light on the differences between the newly release Windows ServiceBus (on premise, not Azure) and NServiceBus?
Looking for a detailed answer what the windows SB may be missing as I'm familiar what NSErviceBus can do:
Is it a real service bus and not just a message broker that uses queues?
Can it support message polymorphism? (Messages subclassing other
messages and handlers supporting this hierarchy
Long running processes and correlation
Scale out
I'm responsible for the Windows Azure ServiceBus support in NServicebus. And in my opinion this new Windows Server Servicebus provides the exact same capabilities as the Azure ServiceBus. So in my opinion it will be a good match with NServiceBus instead of a competitor (just as the Windows Azure ServiceBus is) and could be used instead of msmq.
To answer your questions
The new servicebus is a broker that uses queues
Messages on the servicebus are just strings in the end, the servicebus itself has no additional support for message types, hierarchies, handlers etc. Typically you would use WCF or NServiceBus for this.
There is no support for long running processes nor correlation. It does have some feature overlap with NServiceBus though as it can do subcriptions/topics, it can also do deferral of messages as well as filters.
It's designed to scale out.
Hope this helps?
Kind regards,
Yves