github Particular/NServiceBus 4.1.0

latest releases: 9.0.0, 8.2.0, 9.0.0-alpha.10...
10 years ago

To see the full list of commits for this release click here.
This release is fully backwards with previous v4 releases.
If you are affected by any of the issues listed below we recommend you upgrade.

Known issues

  • [#1687] Windows Server 2012 installing MSMQ using Powershell Cmdlet fails.

When using the Install-NServiceBusMSMQ on Windows Server 2012 the command will fail with the error Feature name MSMQ-Container is unknown.. The workaround is to run the following command manually

dism /Online /NoRestart /English /Enable-Feature /all /FeatureName:MSMQ-Server

The fix for this issue is scheduled for the 4.2 release.

New Features Overview

  • [#1362] @SimonCropp did major work to ensure we are disposing of everything that needs to be disposed, we using the awesome Janitor to helps us out 👍

  • [#718, #1230, #1392] The Gateway received quite a few improvements courtesy of @chrisbednarski, here is an overview:

    The need for ACK calls has been removed altogether.

    In 4.0 each message requires at least 2 HTTP calls, message body + ACK (the ACKs are required in case Databus properties are transferred after the message body).
    In 4.1 the Databus properties are sent before the message body, so the need for ACKs has been removed.

    Since there is no need for ACKs, the persistence doesn't have to temporarily store the entire message + headers

    In 4.0 the message body is retrieved from the persistence store during the ACK.
    In 4.1 the only thing that gets stored in the deduplication store is the stable message id + datetime received.

    To enable this new features

    Set LegacyMode="false" in app.config, example:

    <GatewayConfig>
     <Sites>
      <Site Key="SiteA" Address="http://localhost:25899/SiteA/" ChannelType="Http" />
      <!-- Legacy mode means that messages sent to SiteB as well as any replies from SiteB back to Headquarter will use the new forwarder (IForwardMessagesToSites), legacy mode is enabled by default so we are compatible with endpoints prior to v4.1 -->
      <Site Key="SiteB" Address="http://localhost:25899/SiteB/" ChannelType="Http" LegacyMode="false"/>
     </Sites>
     <Channels>
      <Channel Address="http://localhost:25899/Headquarter/" ChannelType="Http" />
    
      <!-- The default channel is the channel that will be set as return address. This means that any replies will come back on this channel-->
      <Channel Address="http://localhost:25899/Headquarter2/" ChannelType="Http" Default="true"/>
     </Channels>
    </GatewayConfig>
  • [#1308] NServiceBus.Powershell.dll is now in nuget 😄, thanks @chrisbednarski;

  • [#1036] Allow specifying handlers order without using First<T>, you can now specify handlers order in a much cleaner way 😄, here is an example:

    class MyOrder : ISpecifyMessageHandlerOrdering
    {
        public void SpecifyOrder(Order order)
        {
            order.Specify(new[] { typeof(FirstHandler), typeof(SecondHandler) });
        }
    }

    Thanks @nbarnwell for the PR

  • [#1476] New overload for Configure.Component, thanks @chrisbednarski for the PR

  • [#1309] Introduce a way to disable audit.
    In v4 we made Audit On by default, and there was no way to disable it (or at least no easy way!).
    To disable Audit, add the following to your EndpointConfig file:

    Configure.Features.Disable<Audit>();
  • [#1339] Auditing is now a first level concept.
    Prior to this release a way to enable auditing of messages was to configure forwarding of messages via ForwardReceivedMessagesTo attribute, eg: <UnicastBusConfig ForwardReceivedMessagesTo="audit"/>
    Now in this release we introduce a new configuration section:

    <AuditConfig 
      QueueName="The address to which messages received will be forwarded."
      OverrideTimeToBeReceived="The time to be received set on forwarded messages, specified as a timespan see http://msdn.microsoft.com/en-us/library/vstudio/se73z7b9.aspx"  />

    And if you want to quickly update your config files to use the new way use the following cmdlet:

    PM> Add-NServiceBusAuditConfig

  • [#1342] Introducing a way to control lock modes when using the NHibernate saga persister.
    This change makes the default LockMode UpdateLock and allows to be specified as part of the Saga data class, here is an example:

    [LockMode(LockModes.UpgradeNoWait)]
    public class SagaData : ContainSagaData
    {
        [Unique]
        public virtual int Number { get; set; }
    
        public virtual int NumCalls { get; set; }
    }
  • [#1524] Improvements in the assembly scanner, @mookid8000 (our new family member) has done major work in the assembly scanner;

  • [#1599] Performance improvement in MSMQ transport message receiving;

Most critical bug fixes in this release

  • [#1405] Combination of Costura and Aspose can cause infinite loop, thanks @thirkcircus for reporting and helping us testing the fix;
  • [#1492] Unit Tests fail with ConfigurationErrorsException, thanks @chrisbednarski for PR;
  • [#1481] When using DataBus with multiple subscribers that share the same storage causes exception;
  • [#1384] Use Configure.GetConfigSection for Gateway like other IProvideConfig. thanks @michaelnoonan for the PR;
  • [#1470] NSB checks RavenDB version for testing, thanks @agross for reporting this issue;
  • [#1549] Not supporting generic message handlers, thanks @tkristiansen for reporting this issue;
  • [#1483] If a Satellite fails to start shouldn't the whole endpoint be considered as failed to start, thanks @michaelnoonan for reporting this issue;
  • [#652] Username command line argument not used when assigning queue permissions;
  • [#1512] Deadlocks occur on timeout table and index on endpoint incomplete, thanks @ramonsmits for reporting and providing us with a PR;
  • [#1640] ReturnToSource does not recognize the Id in the message headers and does not return the message;

Obsoleted APIs in this release

  • [#1334] RecoverableAttribute has been obsoleted as recoverable is now the default;

  • [#1402] The IBus batch messaging APIs have been obsoleted.
    This includes the following:

    ICallback SendLocal(params object[] messages);
    void Publish<T>(params T[] messages);
    ICallback Send(params object[] messages);
    ICallback Send(string destination, params object[] messages);
    ICallback Send(Address address, params object[] messages);
    ICallback Send(string destination, string correlationId, params object[] messages);
    ICallback Send(Address address, string correlationId, params object[] messages);
    ICallback SendToSites(IEnumerable<string> siteKeys, params object[] messages);
    ICallback Defer(TimeSpan delay, params object[] messages);
    ICallback Defer(DateTime processAt, params object[] messages);
    void Reply(params object[] messages);
    ICallback SendToSites(IEnumerable<string> siteKeys, params object[] messages);  

    They will be removed in a version 5.0 of NServiceBus.

    Reasons

    There are several reasons for this change.

    Confusing API

    The general perception of these APIs that it was "a way to send multiple messages to a specified destination". Where the behaviour is actually "send all the specified message in a single payload and within a single transaction". This may seem like a semantic difference but it actually a significant difference in behaviour. The reason is that if it was just a simple "send multiple messages" then each message would be handled individually, including message failure. But the "single transaction" behaviour means if the a message fails then all messages will be considered failed an rolled back.

    Message Headers

    Several features within NServiceBus rely on the usage of message headers. It is also a valuable extensibility point for adding features to NServiceBus. Unfortunately the concept of message headers is incompatible with a batch approach to sending messages. Significant complexity is currently in place to work around most of this incompatibility but is is not a viable approach moving forward.

    Still want to send multiple messages

    Many people may have actually been using this API as a simple "way to send multiple messages to a specified destination" and have suffered no problems with the "single transaction" behaviour. If you want to continue using this API for convenience but have messages handled in separate transactions you can write some simple extension methods for IBus to enable this. For example:

    public static class BusExtensions
    {
        public static void MultiSend(this IBus bus, Address address, params object[] messages)
        {
            foreach (var message in messages)
            {
                bus.Send(address, message);
            }
        }
    } 

Where to get it

You can download this release from:

Don't miss a new NServiceBus release

NewReleases is sending notifications on new releases.