1.1.2

Same as v1.1.1 release but this time compiled against NServiceBus v4.4 😄

Where to get it

You can download this release from nuget

1.1.1

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

Bugs

#26 Messages not getting sent when SqlConnection is used inside message handlers

It appears that when custom SQL queries to MS SQL Server (using SqlConnection) are made during the lifetime of a NServiceBus message handler, non-deterministic behavior is resulted. Sometimes ambient transaction is never committed, which results in NServiceBus.RabbitMQ never sending out messages that should be sent. That is apparently because flushing of NSB's unit of work is bound to TransactionCompleted event, which sometimes never launches.

I'm able to work around the issue the following way: instead of letting SqlConnection to automatically enlist to ambient transaction, I'm preventing it using 'Enlist=false' in connection string. I don't use System.Transactions at all with the SqlConnection, but I hook up SqlTransaction using NServiceBus'es IManageUnitsOfWork interface.

The issue can be reproduced: https://github.com/peuramaki/NServiceBus.RabbitMq.Issue26

EDIT: workaround suggested here doesn't fix my production scenario, non-deterministic behavior continues.

It also seems that if I forget to close the SqlConnection (or return it to connection pool), non-deterministic behavior is gone.

Where to get it

You can download this release from nuget

1.1.0

This release consist of these issues that were achieved through these commits.

Improvements

#16 Update the RabbitMQ 3.2.1

#4 Only implicitly create exchanges for types being published. Limit queue ...

Raised by @fhalim
Migrated from by Particular/NServiceBus#1352

Background

We are having a non-NServiceBus endpoint integrate with an NServiceBus endpoint over RabbitMQ. The non-NServiceBus endpoint application creates a temporary queue/exchange pair for itself, does the equivalent of a Bus.Send to the NServiceBus endpoint, expecting a response on the temporary exchange. However, when the NServiceBus endpoint does Bus.Reply, it first tries to create a queue/exchange pair for the recipient and fails because they have already been created, but are temporary instead of permanent.

Fix

This change makes it so that Bus.Send and Bus.Reply do not implicitly attempt to create queue/exchange pairs for the recipient. Only exchanges for the types being published are created implicitly.

Impact

• If the recipient of a Bus.Send or a Bus.Reply does not exist, this will raise an exception. This behavior is in line with the MSMQ endpoint and I think is what we'd expect when we send a command to an endpoint. Queues will only get created by the subscribers that read from them.
  Content trimmed. See full issue

#3 Better exception handling in RabbitMQ ConnectionStringParser

Raised by @SimonCropp
Migrated from by Particular/NServiceBus#1452

• the catch was redundant since the message can be derived from the stack trace
• it did not add the inner exception which would obscure the debugging experience

Fixed here Particular/NServiceBus@f3d93a4

Where to get it

You can download this release from:

• Or nuget