Bot releases are visible (Hide)
Published by indualagarsamy about 10 years ago
As part of this release we had 1 issue closed.
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
Published by andreasohlund about 10 years ago
As part of this release we had 6 commits which resulted in 2 issues being closed.
Response message can now be accessed from callback.
This bug affect version 5 only.
In prior versions it was possible to access the reply message from a callback, this seem to be broken in v5.
The following acceptance test passes against v4.6 but fails for v5:
public class When_using_callback_to_get_message : NServiceBusAcceptanceTest
{
[Test]
Content trimmed. See full issue
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
Published by indualagarsamy about 10 years ago
As part of this release we had 1 issue closed.
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
Published by indualagarsamy about 10 years ago
As part of this release we had 1 issue closed.
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
Published by indualagarsamy about 10 years ago
As part of this release we had 1 issue closed.
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
Published by indualagarsamy about 10 years ago
As part of this release we had 1 issue closed.
Messages handled by a saga that contains a explicit saga id should not be allowed to create a new saga if the given saga can't be found in storage. The saga loader has now been modified to check for the existence of the saga id header and also check that the message is directed to the specific saga by comparing the saga type with the saga type header.
You can download this release from nuget
As part of this release we had 5 commits which resulted in 5 issues being closed.
Store Exception.ToString()
instead of Exception.StackTrace
inside the NServiceBus.ExceptionInfo.StackTrace
header
When exception details are written to the error headers the InnerException
type is captured.
However the Message
and the StackTrace
of InnerException
are not captured.
Same goes for the nested InnerExceptions
and StackTrace
of AggregateException
When HandleEndMessage
or HandleBeginMessage
throw an Error
is logged
However when HandleError
is called a Warn
is logged.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we fixed 2 issues.
This fixes the polarity that checks when to run the clean-up procedure
We updated NService Bus from 3.0.3.32 to 4.6.4. The old version saga stop work.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 3 commits which resulted in 1 issue being closed.
This fixes the polarity that checks when to run the clean-up procedure
You can download this release from nuget
Published by indualagarsamy about 10 years ago
http://docs.particular.net/nservicebus/upgradeguides/4to5
As part of this release we had 97 issues closed.
In order to better follow the release cycle of RavenDB, the RavenDB functionality has been removed from the core into its own repository https://github.com/Particular/NServiceBus.RavenDB and nuget
https://www.nuget.org/packages/NServiceBus.RavenDB
Moved to a separate repo https://github.com/Particular/NServiceBus.Distributor.Msmq and NuGet https://www.nuget.org/packages/NServiceBus.Distributor.MSMQ/
In order to provide the same level of consistency as users that are running with DTC transactions enabled we should introduce a mode of operations that provides those same guarantees without requiring a DTC compliant transport and storage.
The following is the high-level design
Content trimmed. See full issue
To simplify the api by not exposing IBus
methods not relevant for a sendonly bus
The extension points IConfigureRole
, IConfigureRole<T>
and IRole
no longer exist.
AsA_Client
and AsA_Server
can still be used.
AsA_Publisher
has been deprecated and should be replaced with AsA_Server
So where previously this was used
Bus.Publish(Bus.CreateInstance<OrderCancelled>(o =>
{
o.OrderNumber = message.OrderNumber;
o.ClientId = message.ClientId;
}));
Now this is used
Bus.Publish<OrderCancelled>(o =>
{
o.OrderNumber = message.OrderNumber;
o.ClientId = message.ClientId;
});
When the timeout persister logs a warning about a failure it will now include the exception in the log entry
The Action
parameter overload of UnicastBus.Start(Action)` has been removed
This was an overly complex approach to running installers. As such it has been simplified
Too many people forget to override this method. As such it will now be abstract.
by using FormatterServices.GetUninitializedObject
The NSB interfaces dll was created to allow people to have a smaller dependency when creating a messages assembly. With the introduction of unobtrusive messages that is no longer required. As such NServiceBus.dll
will be merged into NServiceBus.Core.dll
. Also the NServiceBus.Interfaces
nuget will be deprecated.
In version 5 multi-message sends is being removed. So serialization of an array of messages is no longer required.
Note that deserialization to an array is still required for backwards compatibility with earlier versions of NSB
In version 5 multi-message sends is being removed. So Wrapping messages is no longer required. It only remains for compatibility with 3.0 endpoints
ISaga
looks like an extension point. But in reality it is an internal concern which allows the framework to gain access to a non-generic version of the sagadata. See #1762
So ISaga
(#1762) and ISaga<T>
(#1765) were obsoleted
The replacement for the is a non-generic base class Saga
. This class is a legitimating extension point, although most scenarios would still use Saga<T>
. All functionality of Saga<T>
will be pushed up to Saga
. Saga<T>
will now inherit from Saga
.
Not used for anything.
With the removal of ISaga
and ISaga<T>
the IConfigurable
interface is redundant.
Since the Predicate is executed at the subscriber side it is not efficient. Also this is a confusing API since
consumer often, incorrectly, believe it is publisher side filtering. Instead create a Handler that does this
filtering logic and then, optionally, calls DoNotContinueDispatchingCurrentMessageToHandlers
. This
Handler should be ordered to run before other handlers.
related to https://github.com/Particular/NServiceBus/issues/1546
The reasons for doing this are as follows
What this means for consumers
Note the earlier versions of NServiceBus will still be compatible and supported for .net 4
For more information on .net 4.5 see
so if a user forgets to have this line Feature.Enable<Sagas>();
but still has a saga no guidance is given as to why that saga is not executed
In fact there is misinformation
Could not find a saga for the message type "Message1". Going to invoke SagaNotFoundHandlers.
When you call Disable on transactions, your call is still wrapped in a transactionscope
So to get rid of all transactional behavior you need to do both
Configure.Transactions.Advanced(a => a.DoNotWrapHandlersExecutionInATransactionScope());
Configure.Transactions.Disable();
Would be better to remove the scope automatically
Fix the incorrect message:
No message found with ID 'NServiceBus.MessageId'. Going to check headers of all messages for one with 'NServiceBus.MessageId' or 'NServiceBus.CorrelationId'.
Since the gateway is a optional component we should pull it out of the core and auto enable it if users reference it.
If one configures the Bus with
Configure.Transactions.Disable();
then no transactions should be used at all (at least I understand this that way).
But even if Transactions are disabled, the MsmqDequeueStrategy
calls TransportReceiver.TryProcess(TransportMessage): bool
which starts a new Transaction scope.
This behavior can currently be fixed, if one set explicitly
Configure.Transactions.Disable(s => s.DoNotWrapHandlersExecutionInATransactionScope());
Content trimmed. See full issue
https://github.com/Particular/NServiceBus.NLog
https://github.com/Particular/NServiceBus.Lo4Net
The startupAction
parameter of UnicastBus.Start
simply executed the action immediately before the actual start of the bus. This provided no real value since a consumer can simply execute said action prior to calling Start
.
Each of the messaging APIs that involve multiple messages on IBus
have been removed. Below is the table on how to replace these.
Old Method | Replacement Method |
---|---|
Publish(T[] messages); | Publish(T message); |
SendLocal(object[] messages); | SendLocal(object message); |
Send(object[] messages); | Send(object message); |
Send(string destination, object[] messages); | Send(string destination, object message); |
Send(Address address, object[] messages); | Send(Address address, object message); |
Send(string destination, string correlationId, object[] messages); | Send(string destination, string correlationId, object message); |
SendToSites(IEnumerable siteKeys, object[] messages); | SendToSites(IEnumerable siteKeys, object message); |
Defer(TimeSpan delay, object[] messages); | Defer(TimeSpan delay, object message); |
Defer(DateTime processAt, object[] messages); | Defer(DateTime processAt, object message); |
Reply(object[] messages); | Reply(object message); |
To capture the version of the users endpoint that is running. Extract the current code (used in side by side mode in the host) and make it available on the core.
var configuration = new BusConfiguration();
configuration.EndpointVersion("1.2.1"))
Replacement is IBus
RavenDB has been split out of the core to a separate NServiceBus.RavenDB assembly. This new assembly targets RavenDB 2.5. Please see docs.particular.net for more information
The new api requires the endpoint name to be specified up front:
configuration.EndpointName("someName");
Replacement is TransportConfig
section instead
Throw an exception if IWantCustomInitialization
is used on anything which doesn't also implement IConfigureThisEndpoint
.
Which means they are global (last one wins) across all bus instances
In PerformanceMonitorUsersInstaller
we have hardcoded the group name to "Performance Monitor Users", which means that for non English OSs, that will not work.
IWantToRunWhenBusStartsAndStops.Start
throws
This case is now explicitly detected and a better exception will be thrown.
In Version 5 log4net is no longer embedded inside NServiceBus
So now this code
builder.ConfigureProperty(typeof(DuplicateClass), "SomeProperty", false);
builder.ConfigureProperty(typeof(DuplicateClass), "SomeProperty", true); // this should remove/override the previous property setting
Will result in SomeProperty
being injected as true
Version 5 now has sensible defaults for logging. So logging will still occur from ProfileManager
even if logging is not yet configured.
In Version 5 reading of the logging config bypasses IConfigurationSource
and goes directly to ConfigurationManager.GetSection
Remove the ordering issues that can result in endpoint name being ignored
You can download this release from nuget
Published by andreasohlund about 10 years ago
It's now 4.6.5 , should be 4.6.0
This needs to be hotfixed since it will force users to add asm redirect when upgrading from 4.6.X to 4.6.5
You can download this release from:
Published by indualagarsamy about 10 years ago
As part of this release we had 16 commits which resulted in 2 issues being closed.
In NServiceBus 4.6.3, in a clustered distributor setup, timeouts and deferred messages are delivered to local queue on workers and not to clustered queue.
Timeout messages and deferred messages are delivered directly to a specific local queue (on the server which requested the timeout/deferring) and not to the clustered queue. This bypasses the regular path which involves removing a message from the storage queue and deliver the destination queue on the worker. The worker does not know this and reports back that it is ready to handle a new message after handling the timeout message, which causes the storage queue to grow.
See question on StackOverflow for more information
When an endpoint tries to send a message and if no routing information has been specified in the configuration, then the endpoint throws an unfriendly exception.
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 3 issues closed.
Since the dawn of time we've only supported 1 encryption key in the ootb encryption(AES) and this makes it close to impossible to switch keys without losing data, messages in SLR, or ERROR queues would have the wrong key and fail to decrypt.
The users only options is either to not switch keys which is no good in terms of security best practices or implement their own ISecurityService
The proposed solution is to allow for secondary keys that we fall back to if decryption fails. This way users can add new primary keys (used to encrypt) but still keep the old key(s) around long enough to be able to process messages in SLR or the error queue.
This bug needs to be backported to all supported versions (v3.3 and up)
Docs here: http://docs.particular.net/nservicebus/unobtrusive-mode-messages suggest that you should use a namespace convention for detecting messages. This is cool and I like this convention however if you follow the convention for events/commands and apply the same convention to messages (eg .DefiningMessagesAs(t => t.Namespace != null && t.Namespace.EndsWith(".Messages"))
it exceptions with the following:
An exception of type 'System.NotSupportedException' occurred in NServiceBus.Core.dll but was not handled in user code
Additional information: IDictionary<T, K> is not a supported property type for serialization, use Dictionary<T,K> instead. Type: NServiceBus.Unicast.UnicastBus Property: MessageDispatcherMappings. Consider using a concrete Dictionary<T, K> instead, where T and K cannot be of type 'System.Object'
I think either the docs should be updated to note this issue and suggest a better pattern or the code should exclude NServiceBus.*.Messages and Unicast.Messages from the scan types.
NServiceBus ships with RavenDB Client v2 embedded as part of the core.
As highlighted previously in this discussion a new nuget/dll was released to work against RavenDB v2.5.
So currently anyone using NServiceBus v4 with RavenDB v2.5 Server need to be running the new integration package otherwise them may lose messages!
To ensure that the correct version of the RavenDB integration is being used we need to modify the Raven check that we do in the Core to restrict the upper bound version to be < 2.5
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 2 issues closed.
Since the dawn of time we've only supported 1 encryption key in the ootb encryption(AES) and this makes it close to impossible to switch keys without losing data, messages in SLR, or ERROR queues would have the wrong key and fail to decrypt.
The users only options is either to not switch keys which is no good in terms of security best practices or implement their own ISecurityService
The proposed solution is to allow for secondary keys that we fall back to if decryption fails. This way users can add new primary keys (used to encrypt) but still keep the old key(s) around long enough to be able to process messages in SLR or the error queue.
This bug needs to be backported to all supported versions (v3.3 and up)
NServiceBus ships with RavenDB Client v2 embedded as part of the core.
As highlighted previously in this discussion a new nuget/dll was released to work against RavenDB v2.5.
So currently anyone using NServiceBus v4 with RavenDB v2.5 Server need to be running the new integration package otherwise them may lose messages!
To ensure that the correct version of the RavenDB integration is being used we need to modify the Raven check that we do in the Core to restrict the upper bound version to be < 2.5
You can download this release from nuget