Chris Patterson
@phatboyg.com
"We didn't write MassTransit because it was easy, we wrote it because we thought it would be easy." -anon
April 7, 2025 at 3:00 PM
"We didn't write MassTransit because it was easy, we wrote it because we thought it would be easy." -anon
As stated in the announcement Q&A, the source code will likely remain open, only with a license change and additional requirement to purchase a license to use the v9 packages.
April 3, 2025 at 1:24 PM
As stated in the announcement Q&A, the source code will likely remain open, only with a license change and additional requirement to purchase a license to use the v9 packages.
Europe is a huge MassTransit market, along with Australia and Asia. Definitely a lot of use in the US, and many consulting companies use it as well for customer application builds. The number of paying support customers is not surprisingly a fairly low percentage overall.
January 25, 2025 at 10:58 PM
Europe is a huge MassTransit market, along with Australia and Asia. Definitely a lot of use in the US, and many consulting companies use it as well for customer application builds. The number of paying support customers is not surprisingly a fairly low percentage overall.
Same, the bus outbox (similar to transactional session in NSB) uses the same IPublishEndpoint/ISendEndpointProvider used to publish/send messages outside of a consumer from the MassTransit mediator or MediatR (within the same container scope). masstransit.io/documentatio...
Transactional Outbox
It is common that a service may need to combine database writes with publishing events and/or sending commands. And in this scenario, it is usually desirable to do this atomically in a transaction. Ho...
masstransit.io
December 5, 2024 at 1:51 PM
Same, the bus outbox (similar to transactional session in NSB) uses the same IPublishEndpoint/ISendEndpointProvider used to publish/send messages outside of a consumer from the MassTransit mediator or MediatR (within the same container scope). masstransit.io/documentatio...
But the idea of providing a synchronous facade on top of what is by nature an asynchronous operation seems like a hack, and very specific to the app model (UI vs background, etc.) - this is why ConfigureAwait and SynchronizationContext's are such a pain to manage within the library code itself.
November 29, 2024 at 3:31 PM
But the idea of providing a synchronous facade on top of what is by nature an asynchronous operation seems like a hack, and very specific to the app model (UI vs background, etc.) - this is why ConfigureAwait and SynchronizationContext's are such a pain to manage within the library code itself.
I'm actually in favor of the new asynchronous API's they've created, as long as they work as expected. I'm seeing issues with MT v8.3.2 likely related to connection/channel management and notifications with disconnects and the way the thread pool is used/limited. I'm ready to engage their team on it
November 29, 2024 at 3:28 PM
I'm actually in favor of the new asynchronous API's they've created, as long as they work as expected. I'm seeing issues with MT v8.3.2 likely related to connection/channel management and notifications with disconnects and the way the thread pool is used/limited. I'm ready to engage their team on it
Are there many people actually using those older EF libraries with any current builds of anything? Most of the people I know using MassTransit with older builds are actually using older/unsupported builds of MassTransit as well. Many seem to take "we aren't upgrading" as a wholesale statement.
November 25, 2024 at 6:29 PM
Are there many people actually using those older EF libraries with any current builds of anything? Most of the people I know using MassTransit with older builds are actually using older/unsupported builds of MassTransit as well. Many seem to take "we aren't upgrading" as a wholesale statement.