Update to MassTransit 3.5.x - no documentation, nothing

544 views
Skip to first unread message

Sandro Lange

unread,
Feb 1, 2017, 3:09:49 AM2/1/17
to masstransit-discuss
Hello,

We've been using MassTransit for quite a while now but with the latest version we are kind of lost as there seems to be no documentation whatsoever and the existing documentation is horrible outdated.
Here are a few things that seem to be different and we don't know how to handle these:

- InMemoryTransportCache vanished - it seems we can't use the InMemoryServiceBus for unit/acceptance tests anymore as the Cache glueing all the different bus instances together has been removed

- RetryPolicy is now based on something called GreenPipes and we used to configure our bus instance with an IRetryPolicy-object using the "SetRetryPolicy" method - it now complains that the call is obsolete and I should rather use the lambda style syntax but there seems to be no way to just set an IRetryPolicy Object but only a RetryPolicyFactory-object - I don't know how to create/use this thing

- the BusControl.Start method no longer returns a bus handle (returns void instead of IBusHandle) which makes me think: Why would I need a BusHandle anyway? 

- using the BusControl.Start method in a ASP.NET MVC environment leads to a complete lockup (it just hangs in the start method - something which works fine in 3.4.x) - maybe I forget to configure something but due to a lack of documentation I don't really know what to do



Chris Patterson

unread,
Feb 1, 2017, 11:57:43 AM2/1/17
to masstrans...@googlegroups.com
Sorry to hear you're so confused with the update, a few answer to your questions.

First, the documentation is now located at http://masstransit-project.com - follow the links.

Second, the transport cache is still there and completely usable - the testing fixtures are now using the test harnesses built into MT (none of this was previously documented, but no new documentation has been written either).

You can use the obsolete methods, or you can use the new SetRetryPolicy passing x => IRetryPolicy-object, it's fine but not the best way to take advantage of the syntax.

You should also be using StartAsync(), which returns the bus handle. the Start() method is an extension method. And honestly, you can just use Start/Stop on the buscontrol, the handle is kept internally anyway. It was too hard to manage it with IOC containers.

Again, _busControl.Start() shouldn't be locking up, I use it all the time from the Global.asax Application_Start() method (and call Stop in Application_End).

Check out the latest sample, as it uses all this stuff:



--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/43f322c6-6b48-4d4e-b845-899e25523fad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alexey Zimarev

unread,
Feb 1, 2017, 12:29:26 PM2/1/17
to masstransit-discuss
Check http://masstransit-project/MassTransit for documentation.

Old retry policy methods work and the new retry policy configuration is documented. Yes, it is based on GreenPipes but the dependency is added automatically if you use NuGet packages.

Sandro Lange

unread,
Feb 1, 2017, 12:39:20 PM2/1/17
to masstransit-discuss
Phew ... thank you for the clarification, i will take a try with your sample... the documentation on the masstransit website is a good idea,however when i looked it up earlier this day i could only find old example... odd...

Alexey Zimarev

unread,
Feb 1, 2017, 12:41:39 PM2/1/17
to masstransit-discuss
http://masstransit-project.com/MassTransit/usage/retries.html - here are samples and they are there since last week.

Sandro Lange

unread,
Feb 3, 2017, 3:49:02 AM2/3/17
to masstransit-discuss
Hmm ... but the samples don't explain how to put a whole retrypolicy object into the UseRetry-block - we have an abstract layer on top of the service bus implementation and would like to have it configurable from the outside.
I will figure out a way to do it - just thought it would be great if you could document it.


Another thing:

there is the documentation about the InMemoryCache functionality but I don't seem to find it in any namespace any more. Chris told me, it's inside the InMemoryTestHarness but I'm not sure how to use this and if this is really the thing I need.

Sandro Lange

unread,
Feb 3, 2017, 3:58:48 AM2/3/17
to masstransit-discuss
I ended up using the above mentioned way to pass the retryPolicy:

 x.UseRetry(c => c.SetRetryPolicy(f => retryPolicy));

hope this is correct.

Sandro Lange

unread,
Feb 3, 2017, 4:01:38 AM2/3/17
to masstransit-discuss
And about the InMemoryTransportCache:

It should now be:

var inMemoryTransportCache = new InMemoryHost(Environment.ProcessorCount);

[...]

x.SetHost(inMemoryTransportCache)

right? That's at least what I got out of the git repository.

Benjamin Wegman

unread,
Feb 3, 2017, 1:34:16 PM2/3/17
to masstransit-discuss

Sorry to hear you're so confused with the update, a few answer to your questions.

Just replying here to thank Chris and the others for all the hard work they are putting into this project. No need to say sorry that the documentation is lagging a bit behind after all that work. We have been using MassTransit for a couple of years now and are really happy with the way it has been working. Recently finished updating from version 2 and are now happily running MT3 with just a few minor issues.

Thanks again!

Chris Patterson

unread,
Feb 3, 2017, 1:53:39 PM2/3/17
to masstrans...@googlegroups.com
Thanks, it's great to receive feedback like this, I love it when it just works (once you figure it out!).


--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.

Sandro Lange

unread,
Feb 6, 2017, 3:41:44 AM2/6/17
to masstransit-discuss
Of course, we also love MassTransit! No offence. We've been using it for years now in a very huge project!


Am Freitag, 3. Februar 2017 19:53:39 UTC+1 schrieb Chris Patterson:
Thanks, it's great to receive feedback like this, I love it when it just works (once you figure it out!).

On Fri, Feb 3, 2017 at 10:34 AM, Benjamin Wegman <bwe...@gmail.com> wrote:

Sorry to hear you're so confused with the update, a few answer to your questions.

Just replying here to thank Chris and the others for all the hard work they are putting into this project. No need to say sorry that the documentation is lagging a bit behind after all that work. We have been using MassTransit for a couple of years now and are really happy with the way it has been working. Recently finished updating from version 2 and are now happily running MT3 with just a few minor issues.

Thanks again!

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

Sandro Lange

unread,
Apr 16, 2018, 10:34:36 AM4/16/18
to masstransit-discuss
Again me, this time update to Version 4.x. And guess what: The usage of the InMemoryTransport-Cache thing again is broken.

What we want to achieve: 

Share a transport Cache between multiple instances of the InMemory-Servicebus. In Version 3.x we had to add an InMemoryTransport-Cache via SetHost like this

  var bus = Bus.Factory.CreateUsingInMemory(x =>
            {
                x.SetHost(_inMemoryTransportCache);
}

we initialized this transport-cache like this:

   _inMemoryTransportCache = new InMemoryHost(Environment.ProcessorCount));

Now this is no longer supported as the InMemoryHost-Constructor has at least one additional parameter of type IHostTopology. I honestly don't know what to provide there and how to get it working :/

We want to use this InMemoryBus for both publishing messages and subscribing to these - basically only for testing.

Chris Patterson

unread,
Apr 17, 2018, 9:43:11 AM4/17/18
to masstrans...@googlegroups.com
Sharing a host between two bus instances is no longer supported.


On Mon, Apr 16, 2018 at 7:34 AM, Sandro Lange <sandro...@gmail.com> wrote:
Again me, this time update to Version 4.x. And guess what: The usage of the InMemoryTransport-Cache thing again is broken.

What we want to achieve: 

Share a transport Cache between multiple instances of the InMemory-Servicebus. In Version 3.x we had to add an InMemoryTransport-Cache via SetHost like this

  var bus = Bus.Factory.CreateUsingInMemory(x =>
            {
                x.SetHost(_inMemoryTransportCache);
}

we initialized this transport-cache like this:

   _inMemoryTransportCache = new InMemoryHost(Environment.ProcessorCount));

Now this is no longer supported as the InMemoryHost-Constructor has at least one additional parameter of type IHostTopology. I honestly don't know what to provide there and how to get it working :/

We want to use this InMemoryBus for both publishing messages and subscribing to these - basically only for testing.


Am Montag, 6. Februar 2017 09:41:44 UTC+1 schrieb Sandro Lange:
Of course, we also love MassTransit! No offence. We've been using it for years now in a very huge project!


Am Freitag, 3. Februar 2017 19:53:39 UTC+1 schrieb Chris Patterson:
Thanks, it's great to receive feedback like this, I love it when it just works (once you figure it out!).

On Fri, Feb 3, 2017 at 10:34 AM, Benjamin Wegman <bwe...@gmail.com> wrote:

Sorry to hear you're so confused with the update, a few answer to your questions.

Just replying here to thank Chris and the others for all the hard work they are putting into this project. No need to say sorry that the documentation is lagging a bit behind after all that work. We have been using MassTransit for a couple of years now and are really happy with the way it has been working. Recently finished updating from version 2 and are now happily running MT3 with just a few minor issues.

Thanks again!

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsubscribe...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

Sandro Lange

unread,
Apr 18, 2018, 2:20:30 AM4/18/18
to masstransit-discuss
That would explain a lot. So what is the best approach to test masstransit in unit, ui and acceptance-tests? Which transport should we choose?


Am Dienstag, 17. April 2018 15:43:11 UTC+2 schrieb Chris Patterson:
Sharing a host between two bus instances is no longer supported.

On Mon, Apr 16, 2018 at 7:34 AM, Sandro Lange <sandro...@gmail.com> wrote:
Again me, this time update to Version 4.x. And guess what: The usage of the InMemoryTransport-Cache thing again is broken.

What we want to achieve: 

Share a transport Cache between multiple instances of the InMemory-Servicebus. In Version 3.x we had to add an InMemoryTransport-Cache via SetHost like this

  var bus = Bus.Factory.CreateUsingInMemory(x =>
            {
                x.SetHost(_inMemoryTransportCache);
}

we initialized this transport-cache like this:

   _inMemoryTransportCache = new InMemoryHost(Environment.ProcessorCount));

Now this is no longer supported as the InMemoryHost-Constructor has at least one additional parameter of type IHostTopology. I honestly don't know what to provide there and how to get it working :/

We want to use this InMemoryBus for both publishing messages and subscribing to these - basically only for testing.


Am Montag, 6. Februar 2017 09:41:44 UTC+1 schrieb Sandro Lange:
Of course, we also love MassTransit! No offence. We've been using it for years now in a very huge project!


Am Freitag, 3. Februar 2017 19:53:39 UTC+1 schrieb Chris Patterson:
Thanks, it's great to receive feedback like this, I love it when it just works (once you figure it out!).

On Fri, Feb 3, 2017 at 10:34 AM, Benjamin Wegman <bwe...@gmail.com> wrote:

Sorry to hear you're so confused with the update, a few answer to your questions.

Just replying here to thank Chris and the others for all the hard work they are putting into this project. No need to say sorry that the documentation is lagging a bit behind after all that work. We have been using MassTransit for a couple of years now and are really happy with the way it has been working. Recently finished updating from version 2 and are now happily running MT3 with just a few minor issues.

Thanks again!

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

Alexey Zimarev

unread,
Apr 18, 2018, 2:21:00 PM4/18/18
to masstrans...@googlegroups.com
You can use in-memory test harness or RMQ test harness.

The best approach for integration testing today is to use Docker Compose imo.

Chris Patterson

unread,
Apr 19, 2018, 10:20:41 AM4/19/18
to masstrans...@googlegroups.com
You don't need Docker for unit tests.

Use the in-memory transport for your unit tests, there are hundreds of them in MassTransit.Tests, and the various other unit test projects in the repo to use as examples. 

Everything from sagas, consumers, state machines, etc. It's all in there, and it's all using the in-memory transport.


--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

Alexey Zimarev

unread,
Apr 19, 2018, 2:25:31 PM4/19/18
to masstransit-discuss
I said nothing about unit tests. In distributed systems, unit tests have limited value. End-to-end test need real transport and coordinated environments.

Sandro Lange

unread,
Apr 23, 2018, 3:05:51 AM4/23/18
to masstransit-discuss
Ok, as far as I understood it: 

for unit-tests (one process) we can still use the in-memory transport, for multiple processes (i.e. integration oder GUI tests) we can't use it anymore as there is no shared transport cache.  

correct?


Am Donnerstag, 19. April 2018 16:20:41 UTC+2 schrieb Chris Patterson:
You don't need Docker for unit tests.

Use the in-memory transport for your unit tests, there are hundreds of them in MassTransit.Tests, and the various other unit test projects in the repo to use as examples. 

Everything from sagas, consumers, state machines, etc. It's all in there, and it's all using the in-memory transport.

On Wed, Apr 18, 2018 at 11:20 AM, Alexey Zimarev <azim...@gmail.com> wrote:
You can use in-memory test harness or RMQ test harness.

The best approach for integration testing today is to use Docker Compose imo.

> On 18 Apr 2018, at 08:20, Sandro Lange <sandro...@gmail.com> wrote:
>
> That would explain a lot. So what is the best approach to test masstransit in unit, ui and acceptance-tests? Which transport should we choose?
>
>

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

Chris Patterson

unread,
Apr 23, 2018, 11:13:27 AM4/23/18
to masstrans...@googlegroups.com
I guess yes? Unit tests, absolutely.

I don't know what the other way it was being used entails, but I'm going to guess if you were sharing the host, no


On Mon, Apr 23, 2018 at 12:05 AM, Sandro Lange <sandro...@gmail.com> wrote:
Ok, as far as I understood it: 

for unit-tests (one process) we can still use the in-memory transport, for multiple processes (i.e. integration oder GUI tests) we can't use it anymore as there is no shared transport cache.  

correct?

Am Donnerstag, 19. April 2018 16:20:41 UTC+2 schrieb Chris Patterson:
You don't need Docker for unit tests.

Use the in-memory transport for your unit tests, there are hundreds of them in MassTransit.Tests, and the various other unit test projects in the repo to use as examples. 

Everything from sagas, consumers, state machines, etc. It's all in there, and it's all using the in-memory transport.

On Wed, Apr 18, 2018 at 11:20 AM, Alexey Zimarev <azim...@gmail.com> wrote:
You can use in-memory test harness or RMQ test harness.

The best approach for integration testing today is to use Docker Compose imo.

> On 18 Apr 2018, at 08:20, Sandro Lange <sandro...@gmail.com> wrote:
>
> That would explain a lot. So what is the best approach to test masstransit in unit, ui and acceptance-tests? Which transport should we choose?
>
>

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsubscribe...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages