Bot releases are hidden (Show)
Published by seanfarmar almost 11 years ago
This patch release includes the following bug fixes:
RequestTimeout
crashes with an item with the same key has already been added https://github.com/NServiceBus/ServiceBus/issues/1323
AzureMessageQueueReceiver.GetMessage
to resolve failure to get messages from queue unde high load https://github.com/NServiceBus/NServiceBus/pull/1312
The binaries are available via NuGet and http://particular.net/downloads
Published by SimonCropp almost 11 years ago
To see the full list of issues see Milestone 4.2.0.
To see the full list of commits see this compare.
Partially inspired by the Fubu Russian doll model the internal execution of handlers now takes a nested execution approach.
We refer to this nested approach referred to as a Chain
. Each step in this Chain
is referred to as a Behavior
.
So part of the chain would be
Start chain
invokes ApplyIncomingMessageMutatorsBehavior
invokes CallbackInvocationBehavior
invokes LoadHandlersBehavior
invokes SagaPersistenceBehavior
invokes InvokeHandlersBehavior
This allows each behavior to have control of
The logic should be disabled and give a warning that configs are not consistent.
Related to https://github.com/Particular/NServiceBus/issues/1716
The NServiceBus.Host32
package 4.1.1 does not contain NServiceBus.Host32.exe
, but NServiceBus.Host.exe
The output from CorFlags
illustrates the issue
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1
T4 Scaffolding are not adding much value. Also there are compatibility issues with Visual Studio 2013
When child containers is used. Fix is to upgrade Autofac to 3.0.1
Rollback of Issue 397 (Nested lifetime scopes aren't disposed when the parent is disposed) due to memory leak.
Fails with the error
Error: 0x800f080c
Feature name MSMQ-Container is unknown.
A Windows feature name was not recognized.
Change to use the /all
option in DISM
on Server 2012
Add a check to see if the key exists
Historically ImpersonateSender
was renamed to RunHandlersUnderIncomingPrincipal
as part of #1104.
However the new API adds little clarity.
Dissecting RunHandlersUnderIncomingPrincipal
gives the impression that "Handlers will be run under the principal of the user who sent the message"
When in reality all this API is about is "telling the handler who made the call" not anything to do with security or impersonation. It does this by setting Thread.CurrentPrincipal
to a fake principal containing the username of the user who sent the message. It extracts this username from the message headers. The handler code is free use use Thread.CurrentPrincipal
or to ignore. Either way all handler code will be run under the account the process is running as.
This API will be removed. If people want to access the sending user they can do so by using the message headers like they do for any other message metadata.
Fix so that ReturnToSource is backwards compatible with earlier versions
TimeToBeReceivedAttribute
has an empty constructor and hence TimeToBeReceived
is optional. This should not be the case. The empty constructor should be obsoleted and then removed.
From the Castle Windsor Release Notes
It fixes a problem some users encountered, when CallContext scoped lifestyle is used in certain cross-AppDomain contexts. It specifically affected users of some testing framework or NServiceBus when deployed to Azure. The bug would manifest itself with the following exception:
SerializationException — Type is not resolved for member
“Castle.MicroKernel.Lifestyle.Scoped.CallContextLifetimeScope+SerializationReference,
Castle.Windsor, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc”
You can download this release from:
Published by johnsimons almost 11 years ago
To see the full list of commits for this release click here.
This release is fully backwards with previous v4 releases.
This affects only users that do not have .NET v4.5 installed.
You can download this release from:
Published by johnsimons about 11 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.
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.
[#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:
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.
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.
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;
[#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.
There are several reasons for this change.
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.
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.
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);
}
}
}
You can download this release from:
Published by johnsimons about 11 years ago
This patch release fixes the following issues:
This release is fully backwards with previous v4 releases.
If you are affected by any of the above issues we recommend you upgrade.
You can download this release from here:
Published by SimonCropp about 11 years ago
This patch release fixes the following issues:
HttpChannelReceiver
uses HttpListener.Stop
instead of HttpListener.Close
Those using the Gateway inside a web application should upgrade as you may experience intermittent issued during app-pool restarts.
This release is fully backwards compliant with previous v4 releases.
Thanks to @michaelnoonan helping us verify the fixes!
You can download this release from here:
http://particular.net/downloads
or get it via nuget.
Published by andreasohlund about 11 years ago
This patch release fixes the following issues:
Due to bug #1443 we recommend that all v4 users upgrade to this version.
This release is fully backwards compliant with previous v4 releases.
Thanks to @joeschick and @michaelnoonan for providing an excellent bug reports with easy steps to reproduce!
You can download this release from here:
http://particular.net/downloads
or get it via nuget.