Bot releases are visible (Hide)
Published by andreasohlund about 10 years ago
Legacy release, release notes TBD
Published by johnsimons about 10 years ago
As part of this release we had 1 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 2 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Bugs
#2300 Raven check needs to include an upper bound range
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
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 2 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Bugs
#2300 Raven check needs to include an upper bound range
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
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 3 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Bugs
#2319 Convention based .DefiningMessagesAs causes an exception when following pattern in docs
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.
#2300 Raven check needs to include an upper bound range
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
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 3 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Bugs
#2319 Convention based .DefiningMessagesAs causes an exception when following pattern in docs
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.
#2300 Raven check needs to include an upper bound range
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
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 3 issues closed.
Features
#2287 Enable users to switch encryption keys without message loss
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)
Bugs
#2319 Convention based .DefiningMessagesAs causes an exception when following pattern in docs
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.
#2300 Raven check needs to include an upper bound range
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
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2250 Make sure MsmqWorkerAvailabilityManager is thread safe on .NET 4 in NSB 3.3.9
MsmqWorkerAvailabilityManager.ClearAvailabilityForWorker() throws "System.InvalidOperationException: Property ResponseQueue was not retrieved when receiving the message. Ensure that the PropertyFilter is set correctly" if you put some stress on it with NSB 3.3.9 on .NET 4+.
The problem is that Microsoft made almost everything on MessageQueue NOT thread safe between .NET 3.5 and .NET 4.
3.5 docu: http://msdn.microsoft.com/en-us/library/system.messaging.messagequeue(v=vs.90).aspx vs
4 docu: http://msdn.microsoft.com/en-us/library/system.messaging.messagequeue(v=vs.100).aspx
Those changes by Microsoft makes the MsmqWorkerAvailabilityManager implementation in 3.3.9 not safe, as it needs locking to work. The proposed fix, which fixes the repro, is basically to revert @7de28f8f1dbfdf39a810800b841b0df49f02aac6. Bad luck on that one, @andreasohlund. :)
Check out repro, available here.
Content trimmed. See full issue
Where to get it
You can download this release from nuget
Published by SimonCropp about 10 years ago
Compatibility and Upgrades
Prerequisite: NServiceBus V4.0 requires RavenDB 2.0.0.2261 or later
NServiceBus V4.0 requires the latest RavenDB v2.x to be installed on the same machine.
- You can manually validate the currently installed version of RavenDB by connecting to the RavenDB instance (http://localhost:8080) and examining the bottom status bar where the server and client build numbers are noted. Build numbers prior to 2000 indicate a RavenDB version earlier than 2.x.
- If there is no existing and active installation of RavenDB v2.x on the machine, the NServiceBus installer automatically installs RavenDB v2.x.
- If the NServiceBus V4.0 installer finds a RavenDB version prior to 2.x on the target machine, it installs a new instance of RavenDB v2.x with no impact on the existing instance.
NServiceBus V4.0 is not compatible with NServiceBus V2.6 (or earlier)
As you can see, a large number of features were added to NServiceBus. As a result, NServiceBus V4.0 is not compatible with NServiceBus V2.6. Furthermore, only messages marked as events (IEvent or DefiningEventsAs()) will be auto-subscribed.
PowerShell cmdlets - breaking changes
NServiceBus.Host no longer supports /installinfrastructure. Use PowerShell cmdlets instead.
PowerShell cmdlets have been renamed so that they do not clash with any existing cmdlets. See details below.
Autosubscriptions
Only messages marked as events (IEvent or DefiningEventsAs()) will be auto-subscribed.
Default transaction isolation level
The default transaction isolation level is now ReadCommitted. To revert to Serializable, use this code:
Configure.Transactions.Advanced(settings =>
settings.IsolationLevel(IsolationLevel.Serializable));
Working with Error and Audit queues
The Management Service (installed with NServiceBus V4.0) consumes the messages from the defined MSMQ Error and Audit queues. While the Management Service is running, you can view the the Error messages by viewing the Error.log queue, and auditing data can be viewed using ServiceInsight. You can manage the Management Service (named "Particular.Management") like any other Windows Service (see MSDN article on how to "Start, stop, pause, resume, or restart a service").
Callback behaviour when scaling out
When using a broker based transport endpoints will use a unique input per machine by default unless running the NServiceBus Host in As_aServer or As_aPublisher. This ensures callbacks work as expected when scaling out. If you are not using callbacks use Configure.ScaleOut(s=>s.UseSingleBrokerQueue()); to use the same central queue.
Namespace changes to Types and Interfaces
INeedInitialization: Prior to NServicebus 4.0, The interface INeedInitialization was defined in NServiceBus.Config. In NServicebus 4.0, it is defined at the higher namespace level, i.e NServiceBus. If you receive the following compiler error, please remove the using reference to NServiceBus.Config and resolve using NServiceBus: error CS0104:
'INeedInitialization' is an ambiguous reference between 'NServiceBus.INeedInitialization' and 'NServiceBus.Config.INeedInitialization'
NServiceBus.WebService: Exposing an endpoint as a WebService using NServiceBus.Webservice<YourMessage, YourEnum> has been deprecated in 4.0. Use the WcfService option instead. For example:
YourWcfService : WcfService<YourMessage, YourEnum>
SecondLevelRetries: The type SecondLevelRetries (used in the NServiceBus.Management.Retries namespace to configure the retry and the timeout policy) has been moved to the NServiceBus.Features namespace. While version 3.3.x had a separate policy for managing second level retries and timeouts, this has been merged into the new RetryPolicy in NServiceBus 4.0 and it is capable of achieving both functions.
TransactionalTransport: The type TransactionalTransport, which used to be defined in the namespace NServiceBus.Unicast.Transport.Transactional has been renamed to TransportReceiver and moved to the namespace NServiceBus.Unicast.Transport. If you receive the following compiler error, resolve using the new namespace specified above.
error CS0246: The type or namespace name 'TransactionalTransport' could not be found (are you missing a using directive or an assembly reference?)
New Transports Support and Configuration
These new transport samples were added to the NServiceBus samples, illustrating how to configure the new transports:
- Messaging.ActiveMQ
- Messaging.RabbitMQ
- Messaging.SqlServer
- Messaging.MSMQ
New configuration APIs simplify the transports configuration and make it consistent across all transports. In your config file, specify a connection string, like this:
<connectionStrings>
<!-- MSMQ -->
<add name="NServiceBus/Transport" connectionString="deadLetter=true;
journal=true;useTransactionalQueues=true;
cacheSendConnection=true"/>
<!-- ActiveMQ -->
<add name="NServiceBus/Transport"
connectionString="ServerUrl=activemq:tcp://localhost:61616"/>
<!-- RabbitMQ-->
<add name="NServiceBus/Transport"
connectionString="host=localhost"/>
<!-- SqlServer -->
<add name="NServiceBus/Transport"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=nservicebus;
Integrated Security=True"
/>
</connectionStrings>
You then have two options to specify the transport:
Specify it as part of the IConfigureThisEndpoint class declaration, e.g.:
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server,
UsingTransport<RabbitMQ>
Or specify it in the IWantCustomInitialization.Init method,
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server,
IWantCustomInitialization
{
public void Init(){
Configure.With().DefaultBuilder()
.UseTransport<RabbitMQ>()
}
}
New NuGet packages for the new transports
These NuGet packages are also available:
Example of how to install the NServiceBus.ActiveMQ package
PM> Install-Package NServiceBus.ActiveMQ
New Transport DLLs
Add a reference to the new transport DLLs (in the Binaries directory):
- NServiceBus.Transports.RabbitMQ.dll
- NServiceBus.Transports.SQlServer.dll
- NServiceBus.Transports.ActiveMQ.dll
MSMQ is currently in NServiceBus.Core.dll and does not require any additional reference. NuGet adds the reference automatically.
Configuration Changes
XmlMessageSerializer now supports not wrapping messages in a element for single messages. This makes interoperability with other systems easier.
To turn on this feature:
.XmlSerializer( dontWrapSingleMessages: true )
The MsmqTransportConfig section has been deprecated in favour of TransportConfig section, like this:
<section name="TransportConfig"
type="NServiceBus.Config.TransportConfig, NServiceBus.Core"/>
<TransportConfig MaximumConcurrencyLevel="10" MaxRetries="3"
MaximumMessageThroughputPerSecond="10"/>
INeedToInstallSomething: The INeedToInstallSomething interface is now resolved via the container.
NHibernate Configuration
NHibernate settings have been simplified, as follows:
<appSettings><
!-- dialect is the only required NHibernate property -->
<add key="NServiceBus/Persistence/NHibernate/dialect"
value="NHibernate.Dialect.MsSql2008Dialect"/>
<!-- other optional settings examples -->
<add key="NServiceBus/Persistence/NHibernate/connection.provider"
value="NHibernate.Connection.DriverConnectionProvider"/>
<add key="NServiceBus/Persistence/NHibernate/connection.driver_class"
value="NHibernate.Driver.Sql2008ClientDriver"
/>
<!-- For more settings:
see http://www.nhforge.org/doc/nh/en/#configuration-hibernatejdbc
and http://www.nhforge.org/doc/nh/en/#configuration-optional
-->
</appSettings><
connectionStrings>
<!-- Default connection string for all Nhibernate/Sql persisters -->
<add name="NServiceBus/Persistence"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=nservicebus;
Integrated Security=True"/>
<!-- Optional overrides per persister -->
<add name="NServiceBus/Persistence/NHibernate/Timeout"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=timeout;
Integrated Security=True"/>
<add name="NServiceBus/Persistence/NHibernate/Saga"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=sagas;
Integrated Security=True"/>
<add name="NServiceBus/Persistence/NHibernate/Subscription"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=subscription;
Integrated Security=True"/>
<add name="NServiceBus/Persistence/NHibernate/Gateway"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=gateway;
Integrated Security=True"/>
<add name="NServiceBus/Persistence/NHibernate/Distributor"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=distributor;
Integrated Security=True"/>
</connectionStrings>
Performance Counters
New throughput performance counters and updated performance counters are available:
NServiceBus license installed per machine
Licenses can now be installed in HKLM, allowing you to install one license per server instead of installing a license per endpoint or per Windows account.
LicenseInstaller.exe C:\License.xml
Powershell cmdlet Updates
NServiceBus PowerShell cmdlets have moved to NServiceBus.PowerShell.dll. To import it, run this:
PM> Import-Module .\NServiceBus.PowerShell.dll
NServiceBus Powershell cmdlets have been renamed so they do not clash with any existing cmdlets:
- Installs a NServiceBus license file.
Install-NServiceBusLicense - Displays all messages in a queue.
Get-NServiceBusMSMQMessage - Displays the NServiceBus installed version.
Get-NServiceBusVersion - Installs DTC on the machine.
Install-NServiceBusDTC - Installs RavenDB on the machine.
Install-NServiceBusRavenDB - Installs NServiceBus performance counters on the machine.
Install-NServiceBusPerformanceCounters - Installs MSMQ on the machine.
Install-NServiceBusMSMQ - Validates if DTC is installed and running on the machine.
Test-NServiceBusDTCInstallation - Ensures RavenDB is on the machine.
Test-NServiceBusRavenDBInstallation - Validates that NServiceBus performance counters are correctly installed on the machine.
Test-NServiceBusPerformanceCountersInstallation - Validates MSMQ is correctly installed on the machine.
Test-NServiceBusMSMQInstallation - Adds the required configuration section to the config file.
Add-NServiceBusMessageForwardingInCaseOfFaultConfig - Shows the default error and audit queues.
Get-NServiceBusLocalMachineSettings - Allows specifying the default error and audit queues.
Set-NServiceBusLocalMachineSettings - NServiceBus.Host no longer supports /installinfrastructure. Use PowerShell cmdlets instead.
New Endpoint Configuration API
Sample usage:
Configure.Endpoint.AsSendOnly()
.Advanced(settings => settings.DisableDurableMessages());
Configure.Transactions.Enable()
.Advanced(settings => settings.IsolationLevel(IsolationLevel.Serializable)
.DefaultTimeout(TimeSpan.FromSeconds(40))
.DisableDistributedTransactions());
Embedded RavenDB
RavenDB is not ilmerged anymore. It is embedded instead, using https://github.com/Fody/Costura#readme.
The embedding enables client updates (but may require binding redirects). It also allows passing your own DocumentStore, thereby providing full configuration flexibility.
Audit and Error Queue Defaults
Server defaults for audit and error queues can now be specified in the registry (see new PowerShell cmdlet Get/Set-NServiceBusLocalMachineSettings, above).
Unattended Installation
The NServiceBus installer can be executed in quiet, unattended mode by running the following command:
Particular.NServiceBus-4.0.x.exe /q /l install.log
This will run the installer in quiet mode and create a log file called install.log.
Note that the name of the installer file may differ from the above example, and that running the installer in quiet mode still opens a browser window to the Particular Software website when the installation is completed.
Known Issues
ActiveMQ requires enabling the Scheduler.
You can do this by setting the schedulerSupport="true" attribute to the configuration in activemq.xml:
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost"
dataDirectory="${activemq.data}" schedulerSupport="true">
ActiveMQ Client connection fails when hostname includes a hyphen
See https://issues.apache.org/jira/browse/AMQNET-399.
NMS Client for ActiveMQ
The release contains a custom build of Apache.NMS.ActiveMQ.1.5.6 client. This custom build fixes the following issues:
- AMQNET-412 : Messages are enlisted to the wrong transaction
- AMQNET-413 : Message producers do not respect DTC Transactions correctly
- AMQNET-414 : Exception thrown when using DTC in multiple processes connected to the same broker
- AMQNET-416 : DTC Ressource ManagerID must be configurable
- AMQNET-417 : DTC Recovery should be done once for each application start
- AMQNET-418 : Recovery File Logger does not support multiple concurrent transactions
- AMQNET-419 : The MessageConsumer sometimes does not send a RemoveInfo when closed
- AMQNET-420 : Session does not pass correct last delivered message in the Remove Info
- AMQNET-421 : Replace Mutex by lock
- AMQNET-422 : Added support for transactions for Asyncronous Listeners
The custom build will be removed as soon as the official NMS client is updated with the above fixes.
Installing RavenDB v2.x on a machine that already has RavenDB v1.x
When installing NServiceBus V4.x on a machine where an instance of RavenDB v1.x exists (default listening on port 8080), the installer will identify the existing RavenDB instance and try to capture the next available port (8081, 8082, etc.) instead of the default 8080 port. Once an available port is found, the installer installs RavenDB v2.x instance as a new Windows service, side-by-side with the existing RavenDB v1.x installation.
By the end of the installation there will be two RavenDB services running side by side on the machine:
- RavenDB
- RavenDB v2
To uninstall RavenDB v2, follow these steps:
- Open a command line and navigate to this directory:
%Program Files%\NServiceBus.Persistence.V4 - Execute this command:
Raven.Server.exe –uninstall –service-name=RavenDB-v2
Note that uninstalling NServiceBus (via the installer or through Control Panel > Programs) does not uninstall any RavenDB installations.
###Transport samples do not work with Visual Studio 2010
All the new transports introduced with NServiceBus 4.0 do not work with Visual Studio 2010. The supplied samples currently work only with Visual Studio 2012.
Windows Azure
Updated to the version 2.0 of the storage client.
NHibernate is no longer needed when using NServiceBus on Windows Azure (details).
RabbitMQ
Has improved support for high performance polymorphic pub/sub (details).
Thanks to Fawad Halim and Jeff Sogolov from ADP!
NHibernate
Sagas are now mapped using the table per concrete class strategy to avoid join tables when using base classes for sagas. This improves performance when reading/writing sagas to the database (details).
SQL Server Transport
NOTE: Due to schema changes from NServiceBus V4.0 Beta, to use SQL Server Transport with NServiceBus V4.0, delete any tables created with NServiceBus V4.0 Beta.
- No longer using the deprecated timestamp column type (details).
- Machine name is no longer used in the address for broker based transports. This fixes and issue when scaled out subscribers would receive duplicate messages (details).
- Uses the ROWLOCK hint to make sure that no table locks are used (details).
- Fixed a critical bug in the sql transport where a exception from a message handler would cause the message to be retried indefinitely (details).
- The video store sample has been improved with better naming and also displays how to use our InMemory support for domain events (details).
- Profiles are now working correctly when endpoints are installed as windows services (details).
- Impersonation support renamed to better reflect the actual use case for it (details).
- Improved the API for reacting to profiles being enabled (details).
- Switching between persistence technologies is now easier (details).
- ISagaStartedBy is now obsolete. To start sagas, use IAmStartedByMessages instead (details).
Installing NServiceBus on Windows Server 2012
- When installing NServiceBus v4 on Windows Server 2012, MSMQ must be installed manullay prior to NServiceBus installation. See MSDN article "Installing and Managing Message Queuing" for more details.
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 2 issue closed.
Bugs
#2175 Patch V3 to support "non array wrapped" messages
In version 3.3.8 and JSON we have hard coded the assumption that messages will be wrapped in an array
public object[] Deserialize(Stream stream)
{
JsonSerializer jsonSerializer = JsonSerializer.Create(JsonSerializerSettings);
jsonSerializer.ContractResolver = new MessageContractResolver(_messageMapper);
JsonReader reader = CreateJsonReader(stream);
return jsonSerializer.Deserialize<object[]>(reader);
}
Content trimmed. See full issue
#2238 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2237 Timeouts could be delayed for longer then required
Some timeouts could be delayed firing for a maximum of 2 minutes
Where to get it
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 1 issue closed.
Bugs
#2133 If index is stale we may miss timeouts
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
Where to get it
You can download this release from nuget
Published by indualagarsamy over 10 years ago
As part of this release we had 5 commits which resulted in 1 issue being closed.
Bugs
#2096 Autofac 3.0.0 leaks memory
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.
ported from https://github.com/Particular/NServiceBus/issues/1708
Where to get it
You can download this release from:
To apply the hotfix using Nuget
In Package Manager Console, type:
update-package NServiceBus -version 4.1.2 <ProjectName>
Published by andreasohlund over 10 years ago
As part of this release we had 5 commits which resulted in 1 issue being closed.
Bugs
#1943 Cant Send in 4.2 and Return in 3.x
When a 3.X endpoint does a Bus.Return that targets a 4.2.0 endpoint the v4 endpoint can't process the message. This makes it wire incompatible.
repro https://github.com/Particular/BugsRepro/tree/master/1943MissingCompletionMessage
So in a 4.2 endpoint
Bus.Send("Returner", new Message())
.Register<int>(i => Debug.WriteLine(i));
Content trimmed. See full issue
Where to get it
You can download this release from: