Skip to content

Releases: Particular/NServiceBus.SqlServer

2.1.2

30 Mar 08:46
Compare
Choose a tag to compare

As part of this release we had 3 commits which resulted in 1 issue being closed.

Bug

  • #76 SqlServerStorageContext is not properly registered in the container

Who's affected

All who use SQL Server transport with StructureMap. For other containers only users who wish to access the underlying transport connection or transaction using SqlServerStorageContext class.

Where to get it

You can download this release from nuget

2.1.1

12 Mar 13:18
Compare
Choose a tag to compare

As part of this release we had 4 commits which resulted in 1 issue being closed.

Bug

  • #70 Core assembly is referenced by wrong name when trying to obtain the error queue name using internal core classes

Where to get it

You can download this release from nuget

2.1.0

02 Mar 10:14
Compare
Choose a tag to compare

As part of this release we had 6 issues closed.

Bugs

  • #44 Invalid header values causing NServiceBus to crash

Features

  • #65 Adaptive concurrency
  • #66 Using non-default schema on per-endpoint basis
  • #62 Programmatically manage connection strings for multi database support
  • #57 Moving badly formatted messages to error queue

Improvements

  • #7 Make CircuitBreaker intermittent failure delay configurable

Where to get it

You can download this release from nuget

2.0.2

26 Nov 14:05
Compare
Choose a tag to compare

As part of this patch release we had 1 issue closed.

Bugs

  • When the endpoints use different database as specified in the connection string, Bus.Reply is not routed properly #59

Who is affected

Any endpoint running on SQLServer transport that is calling Bus.Reply() and using multi-database support via app.config connection string convention.

Where to get it

You can download this release from nuget

2.0.1

29 Sep 21:58
Compare
Choose a tag to compare

As part of this release we had 1 issue being closed.

Bugs

#52 When auditing a reply message, the message is sent to the wrong queue

Instead they are sent to the destination specified in the callback header.

This bug was introduced in v2.0.0

Where to get it

You can download this release from:

2.0.0

29 Sep 19:44
Compare
Choose a tag to compare

As part of this release we had 5 issues closed.

Improvements

#48 Make callbacks and pubsub work seamlessly when scaled out

This is handled by using a secondary receive thread that polls the {endpointname}.{machinename} table. All bus.Reply|Return messages will be sent to this queue to make callbacks work.

#38 Move to .net 4.5

#32 Expose the SqlConnection used to receive incoming messages

This will allow users to reuse that connection if needed to avoid escalating to DTC tx.

The reason for DTC escallation is that even if the connection strings are the same escalation will still happen if more than 1 connection is open at the same time. This will always happen since we need to keep the receiving connection open for the duration of the receive

#3 Improve error reporting in SqlServerPollingDequeueStrategy

raised by @russellchadwick

If you neglect to Configure.Instance.ForInstallationOn<Windows>().Install(), SqlServer transport will not create its tables. Later the SqlServerPollingDequeueStrategy will have exceptions because the objects does not exist.

The issue is that the exception reported to log is

WARN  NServiceBus.Transports.SQLServer.SqlServerPollingDequeueStrategy  - Failed to connect to the configured SqlServer

The message is inaccurately reporting a connection failure.

migrated from Particular/NServiceBus#1501
Content trimmed. See full issue

Bugs

#29 Using transport with no DTC

This issue is raised as part of the diagnosing of #17

The problem is that to prevent DTC escalation we cannot use nested ADO connections from within a handler, so we need a way to expose both the ado connection + ado transaction to the end user.

Here is what @andreasohlund said:

Did some research and it seems escalation wont happen if "the connections are not open at the same time"

http://stackoverflow.com/a/1693270/236004

Since we keep the connection open during receive I believe the escalation will happen when a second connection is opened. To fix this we need to share the connection or have the users use our native transaction. Does this make sense?

Content trimmed. See full issue

Where to get it

You can download this release from:

2.0.0 beta1

16 Jul 05:47
Compare
Choose a tag to compare
2.0.0 beta1 Pre-release
Pre-release

As part of this release we had 3 issues closed.

Improvements

#38 Move to .net 4.5

related to Particular/NServiceBus#2078

#3 Improve error reporting in SqlServerPollingDequeueStrategy

If you neglect to Configure.Instance.ForInstallationOn<Windows>().Install(), SqlServer transport will not create its tables. Later the SqlServerPollingDequeueStrategy will have exceptions because the objects does not exist.

The issue is that the exception reported to log is

WARN  NServiceBus.Transports.SQLServer.SqlServerPollingDequeueStrategy  - Failed to connect to the configured SqlServer

The message is inaccurately reporting a connection failure.

Content trimmed. See full issue

#32 Expose the SqlConnection used to receive incoming messages

You can now access the IDbConnection and SqlTransaction from your own sagas and/or handlers.
To do this inject SqlServerStorageContext

Bugs

#29 Using transport with no DTC

This issue is raised as part of the diagnosing of #17

The problem is that to prevent DTC escalation we cannot use nested ADO connections from within a handler, so we need a way to expose both the ado connection + ado transaction to the end user.

Here is what @andreasohlund said:

Did some research and it seems escalation wont happen if "the connections are not open at the same time"

http://stackoverflow.com/a/1693270/236004

Since we keep the connection open during receive I believe the escalation will happen when a second connection is opened. To fix this we need to share the connection or have the users use our native transaction. Does this make sense?

Content trimmed. See full issue

Where to get it

You can download this release from nuget

1.2.2

16 Apr 04:40
Compare
Choose a tag to compare

As part of this release we had 5 commits which resulted in 1 issue being closed.

Bugs

#33 Under load a shutdown could cause current messages to not complete processing

When performing a shutdown while messages were being processed, the current processing messages could end pre-maturely causing an exception to be logged and a graceless shutdown.

Where to get it

You can download this release from nuget

1.2.1

28 Mar 04:42
Compare
Choose a tag to compare

As part of this release we had 2 commits which resulted in 1 issues being closed.

Bugs

#30 NServiceBus.CastleWindsorBuilder can't resolve SqlServerMessageSender.ConnectionStringCollection

When a message arrives in the queue, I get the following exception multiple times. Following trace is from the component "UnicastBus", but i get it from every level in NServiceBus where the message passes.

Castle.Windsor Warning: 0 : Exception when resolving optional dependency Dependency 'MessageSender' type 'NServiceBus.Transports.ISendMessages' on component NServiceBus.Unicast.UnicastBus., Castle.MicroKernel.ComponentActivator.ComponentActivatorException: Error setting property SqlServerMessageSender.ConnectionStringCollection in component NServiceBus.Transports.SQLServer.SqlServerMessageSender. See inner exception for more information.
If you don't want Windsor to set this property you can do it by either decorating it with DoNotWireAttribute or via registration API.
Alternatively consider making the setter non-public. ---> System.NullReferenceException: De objectverwijzing is niet op een exemplaar van een object ingesteld.
   bij Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.SetUpProperties(Object instance, CreationContext context)
   --- Einde van intern uitzonderingsstackpad ---
   bij Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.SetUpProperties(Object instance, CreationContext context)
   bij Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   bij Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   bij Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)

Content trimmed. See full issue

Where to get it

You can download this release from nuget

1.2.0

21 Mar 04:11
Compare
Choose a tag to compare

As part of this release we had 20 commits which resulted in 3 issues being closed.

Features

#15 Support for sending to queues in different databases

When sending a message the MessageSender will check if a specific connectionstring is defined for this queue. If that is the case, the other connectionstring will be used.

The extra connectionstrings can be configured in the web.config like this:

  <connectionStrings>
    <add name="NServiceBus/Transport" connectionString="Data Source=.;Initial Catalog=DBForReceiveQueue; Integrated Security=True" />
    <add name="NServiceBus/Transport/Queue1Name" connectionString="Data Source=.;Initial Catalog=DBForQueue1; Integrated Security=True" />
    <add name="NServiceBus/Transport/Queue2Name" connectionString="Data Source=.;Initial Catalog=DBForQueue2; Integrated Security=True" />
  </connectionStrings>

Content trimmed. See full issue

Bugs

#17 HasActiveTransaction in UnitOfWork class returns true even if the transaction for the current thread has been cleared

The use of IsValueCreated is incorrect, because it will return true regardless if the value is null or not.

    public bool HasActiveTransaction()
    {
        return currentTransaction.IsValueCreated;
    }

The believe the method should check for null values.

    public bool HasActiveTransaction()

Content trimmed. See full issue

Where to get it

You can download this release from: