Change MSMQ to RabbitMQ #185
Comments
|
@alexeyzimarev thanks for raising this. It's an interesting proposition. One thing that we have to bear in mind is that we still want to support the use of VS 2015 for now, which means we have to stick to the old-style verbose csproj format for now, which AFAIK cannot be used in an IDE on non-Windows OS's (correct me if I'm wrong?). Having said that, we would like to move to the new SDK-style csproj ASAP, and we'll be keeping a close eye on the requirement to keep supporting VS 2015, to see when we can drop it. |
|
Rider and MonoDevelop (which also means VS for Mac, but I have not tested) supports any type of But even with the old format, which is in fact, #182, using RabbitMQ will at least enable people to run Mono apps. MSMQ is the biggest issue (among with the mammoth of SQL Server). |
|
I'd rather then change to the Learning Transport, which would then rule out using the platform tools like ServiceControl. So not ideal either. I'm no expert on Docker, but afaik it needs hyper-v on Windows and that means Windows Home won't work. That would mean Windows attendees would have an additional prerequisite to run Windows Pro at the least. Also not ideal. It is indeed an interesting proposition, but I'm not sure it's as easy as it sounds? |
|
May be not, but I don't know the Learning Transport. I know that RMQ can provide great insights about exchanges and queues, which is very useful for learning how things work. Speaking from experience - I have done the MassTransit three-hours workshop three times. Never had a single person running Windows Home. It is a question of priorities. I'd rather support the growing number of people using non-Windows environments, than a hypothetical Windows Home user. |
|
I'd rather avoid the use of Mono for the workshop exercises. NServiceBus is neither tested nor officially supported on Mono and it would come at the risk of causing us a lot of overhead during the workshop. As long as we want to support VS 2015 then we cannot switch to .NET Core, which mean Windows is also going to remain a prerequisite until then. When we decide to drop support for VS 2015 then we can revisit this issue. |
|
Ok, even if you rule out Mono, VS 2015 Update Whatever supports .NET Core. I would still change MSMQ to RMQ, this does not require any changes in project structure or platform. |
|
As far as I can remember VS2015 supports only .NET Core 1.x |
|
We are discussing #182 actually, not this issue :) I closed it. |
|
I'd rather go with the learning transport, that implies zero friction and is fully F5 compliant. Given that with MSMQ subscriptions are message driven they require an explicit routing configuration. By moving to a brokered transport with native support for pub/sub we realized that the transition for users that want to use MSMQ (and we have many) would have been much harder. I'm not opposed to this change, probably it's enough to point to the documentation we have. |
|
I thought we didn't move to LearningTransport because of ServiceControl? |
|
That can be solved by a transport adapter, but when we discussed MSMQ/Brokered we weren't discussing ServiceControl yet. Anyway The monitoring experience is a blocker for the learning transport. Once we can support containers a |
|
I'm not a big fan of the learning transport for this, because it feels a lot more "real" when you're using an actual transport. In the last few classes, I've just demoed RabbitMQ transport because it's good to have a contrast of broker-based transports. |
|
Given that people often come in with corporate laptops, is Docker a reasonable pre-requisite? |
|
Well, say, either Docker and RMQ image, or RMQ installed. They need to develop somehow. |
I'm not sure I agree, because we promote workshop is technology agnostic. Besides that we abstract away both the learning transport, rabbitmq and any other. I know there are differences, but if you don't look at configuration and just focus on sending, publishing and processing messages and the concepts behind the workshop, why would any other transport make a difference? Besides the fact that I see a lot of people struggle setting up Docker on Windows, including myself. It took me quite a while before I had it running. And searching the internet for solutions, I wasn't the only one having issues. It could result in people not being able to do the exercises because they don't have Docker installed. |
|
When I teach the workshop, I explicitly talk about differences between the
different transports, MSMQ and brokers. I even convert an exercise to
RabbitMQ, open up the management UI and show what’s going on. The slides
only cover MSMQ. The audience, when I ask, mainly looks to use brokers.
That’s a big reason for me. It’s a decision that has to be made early and
is difficult to change once you’re in production.
And while the API is the same, your production code does need to change
based on transport. You can’t use outbox in anything but inside a host, for
example.
…On Thu, Jan 25, 2018 at 3:41 AM Dennis van der Stelt < ***@***.***> wrote:
I'm not a big fan of the learning transport for this, because it feels a
lot more "real" when you're using an actual transport.
I'm not sure I agree, because we promote workshop is technology agnostic.
Besides that we abstract away both the learning transport, rabbitmq and any
other. I know there are differences, but if you don't look at configuration
and just focus on sending, publishing and processing messages and the
concepts behind the workshop, why would any other transport make a
difference?
Besides the fact that I see a lot of people struggle setting up Docker on
Windows, including myself. It took my quite a while before I had it
running. And searching the internet for solutions, I wasn't the only one
having issues. It could result in people not being able to do the exercises
because they don't have Docker installed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#185 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGYMjQCMjL8Smdbuc23fctwbkhaLDupks5tOEwwgaJpZM4Qi7K_>
.
|
I think this is the key. This is why I opened this issue. Azure ServiceBus, Windows ServiceBus and RMQ are the main candidates for most people anyway. MSMQ and SQL Server are important for NServiceBus but it is becoming marginal. |
You are certainly right about that. That's an easier decision to make, to do something about the slides to not focus on MSMQ so much. |
MSMQ only works on Windows and I seriously doubt most people will use it in production anyway. I would suggest using RabbitMQ instead and include instructions to get/run it in a Docker container, since this would simplify the setup and will allow using macOS and Linux for the workshop.
The text was updated successfully, but these errors were encountered: