NServiceBus - Ошибки сообщения управления распространителем
Мы купили много лицензий, провели много испытаний с многообещающими результатами и на пороге нашего первого выпуска:).
Но теперь мы столкнулись с большим препятствием на дороге, что означает, что нам, возможно, придется покинуть автобус, если мы не сможем объяснить и исправить это:/.
Наш Дистрибьютор внезапно получил сообщения об ошибках управления, подобные приведенному ниже:
<?xml version="1.0"?>
<ArrayOfHeaderInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<HeaderInfo>
<Key>NServiceBus.ControlMessage</Key>
<Value>True</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.Distributor.WorkerCapacityAvailable</Key>
<Value>20</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.Distributor.WorkerStarting</Key>
<Value>True</Value>
</HeaderInfo>
<HeaderInfo>
<Key>CorrId</Key>
<Value>58dd98f5-9ac0-44fb-8604-3a0f06787a35\295075</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Reason</Key>
<Value>ProcessingFailed</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.ExceptionType</Key>
<Value>System.InvalidOperationException</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.HelpLink</Key>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Message</Key>
<Value>Property ResponseQueue was not retrieved when receiving the message. Ensure that the PropertyFilter is set correctly.</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.Source</Key>
<Value>NServiceBus.Core</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.ExceptionInfo.StackTrace</Key>
<Value> at NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.ProcessMessage(TransportMessage m) in c:\BuildAgent\work\nsb.master_6\src\impl\unicast\transport\NServiceBus.Unicast.Transport.Transactional\TransactionalTransport.cs:line 312
at NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.ReceiveMessage() in c:\BuildAgent\work\nsb.master_6\src\impl\unicast\transport\NServiceBus.Unicast.Transport.Transactional\TransactionalTransport.cs:line 275
at NServiceBus.Utils.TransactionWrapper.RunInTransaction(Action callback, IsolationLevel isolationLevel, TimeSpan transactionTimeout) in c:\BuildAgent\work\nsb.master_6\src\utils\TransactionWrapper.cs:line 32
at NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.Process() in c:\BuildAgent\work\nsb.master_6\src\impl\unicast\transport\NServiceBus.Unicast.Transport.Transactional\TransactionalTransport.cs:line 220</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.OriginalId</Key>
<Value>58dd98f5-9ac0-44fb-8604-3a0f06787a35\295075</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.FailedQ</Key>
<Value>someservice.processId.distributor.control@testservices01</Value>
</HeaderInfo>
<HeaderInfo>
<Key>NServiceBus.TimeOfFailure</Key>
<Value>2013-04-30 10:07:40:750707 Z</Value>
</HeaderInfo>
</ArrayOfHeaderInfo>
Google говорит нам, что это может быть связано с некоторыми проблемами многопоточности и, возможно, даже с тем, как NSB реализован с использованием peek/receive.
Вышеуказанное исключение относится к этому файлу на GitHub: https://github.com/NServiceBus/NServiceBus/blob/master/src/impl/unicast/transport/NServiceBus.Unicast.Transport.Transactional/TransactionalTransport.cs
Подробности о нашей реализации:
Мы используем пользовательский IManageUnitsOfWork из-за некоторой устаревшей проблемы, которая означает, что пока нет никаких DTC для БД. Я не думаю, что это может быть причиной, но я думаю, что стоит упомянуть. Это реализация:
public class ManagedUnitOfWorkWithDtcSuppression : IManageUnitsOfWork
{
private readonly IContainer _container;
private IUnitOfWork _unitOfWork;
private readonly TransactionScope _scope;
public ManagedUnitOfWorkWithDtcSuppression()
{
_scope = new TransactionScope(TransactionScopeOption.Suppress);
_container = ObjectFactory.GetInstance<IContainer>();
}
public void Begin()
{
_unitOfWork = _container.GetInstance<IUnitOfWork>();
}
public void End(Exception exception = null)
{
if (exception == null)
{
_unitOfWork.Commit();
}
_unitOfWork.Dispose();
_scope.Complete();
_scope.Dispose();
}
}
Также у нас есть специальная настройка, в которой мы запускаем 4 идентичных домена приложений внутри 1 запущенной службы, что означает, что когда мы запускаем службу в качестве распространителя, фактически работают 4 распространителя. Но это пр. определение полностью изолированы друг от друга. IBus уникален для каждого AppDomain, это было проверено.
Наша конфигурация дистрибьютора выглядит следующим образом:
return NServiceBus.Configure.With()
.DefineEndpointName(queuePrefix)
.Log4Net(ObjectFactory.GetInstance<IServiceBusLog>().Build())
.StructureMapBuilder()
.JsonSerializer()
.AsMasterNode()
.RunDistributorWithNoWorkerOnItsEndpoint()
.MsmqTransport()
.IsTransactional(true)
.DisableTimeoutManager()
.DisableSecondLevelRetries()
.UnicastBus()
.CreateBus()
.Start(() => NServiceBus.Configure.Instance.ForInstallationOn<NServiceBus.Installation.Environments.Windows>().Install());
Вопрос:
Что здесь происходит?
Мы облажались с NSB, потому что мы используем подавление DTC, есть ли ошибка MSMQ или есть ошибка NSB?
1 ответ
Позвольте мне получить ответ с опозданием на год!:) Я почти уверен, что вы видите https://github.com/Particular/NServiceBus/pull/2250. По сути, Microsoft внесла изменения в реализацию MessageQueue между.NET 3.5 и.NET 4, сделав код NSB небезопасным. Это было исправлено в https://github.com/Particular/NServiceBus/releases/tag/3.3.10