问题标签 [nservicebus4]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
nservicebus - NServiceBus 4.0 - 重复消息
NServiceBus 是否保证一条消息不被多个线程处理?
我一直在这种假设下工作,但是似乎一条消息同时处理了两次。
我们在处理程序中做了一些非事务性的事情,所以在我们的配置中我们指定DoNotWrapHandlersExecutionInATransactionScope
. 这会影响 NServiceBus 确保消息只处理一次的能力吗?据我了解,这正是它所说的并且不包含事务范围?
有人可以帮我解决这个问题吗?还有什么可能导致重复消息问题?
nservicebus4 - NServiceBus 消息可以具有匿名类型属性吗?
我有一个Payload
类型的属性object
。
我用匿名类型填充 Payload,然后将其发送出去,然后我得到了这个丑陋的错误:
c# - NServiceBus.CastleWindsorBuilder 无法解析 SqlServerMessageSender.ConnectionStringCollection
任何人都可以帮我解决以下问题,这似乎只发生在最新的 NServiceBus 升级(4.3 -> 4.4.2)之后。
我们正在创建一个 MVC4 应用程序,它应该接收来自其他应用程序的消息。NServiceBus 自托管在同一个应用程序中。
使用以下软件包:
- 温莎城堡 3.2.1 和城堡核心 3.2.2
- 用于整个应用程序的依赖关系解析
- NServiceBus 4.4.2
- NServiceBus CastleWindsor 4.4.2
- 合理的选择,因为我已经将 Castle 用于应用程序的其余部分
- NServiceBus SqlServer
- 出于监控原因,我们更喜欢数据库表而不是 msmq
以下代码用于初始化 NServiceBus
在 Global.asax Application_Start 中,此安装程序被安装在全局 windsor-container 中。
当消息到达队列时,我多次收到以下异常。以下跟踪来自组件“UnicastBus”,但我从消息传递的 NServiceBus 中的每个级别获取它。
最终,消息不会被转发到错误队列,并且 NServiceBus 会关闭。
在检查这个异常跟踪时,我发现 SqlServerMessageSender.ConnectionStringCollection 已经有一个私有设置器,所以我想知道为什么 Castle.Windsor 没有成功创建 MessageSender 的实例。
去完成:
网络配置包含
有人知道为什么会发生此异常吗?
nservicebus - NServiceBus - 嵌套全双工方案
我是 NServiceBus 的新手,玩 NServiceBus 示例的时间不超过两天。我查看了 Full Duplex 消息传递示例,它对我来说很好用。
但是现在,我正在尝试实现一个嵌套的全双工场景,其中
- 我的客户端端点“A”将向服务器端点“B”发送一条消息并等待来自“B”的回复
- 我的服务器端点“B”将向服务器端点“C”发送一条消息并等待来自“C”的回复
- 服务器端点“C”将回复服务器端点“B”然后
- 服务器端点“B”将回复客户端端点“A”
我已经从示例代码(当然更改了项目名称和命名空间等)复制了服务器端点以具有两个服务器端点,但是来自客户端“A”的消息到达服务器“B”,无法发布它到服务器“C”。我得到的只是几次重试,后来又失败了。
WARN NServiceBus.Faults.Forwarder.FaultManager [(null)] <(null)> - 消息 FLR 失败,将移交给 SLR 进行重试:4,MessageID=c07c5e38-f355-4f01-a67d-a30a011545a1。
ERROR NServiceBus.SecondLevelRetries.SecondLevelRetriesProcessor [(null)] <(null)> - SLR 未能解决消息 c07c5e38-f355-4f01-a67d-a30a011545a1 的问题,并将被转发到错误队列
我的问题是,这是否是我正在尝试的无效 NServiceBus 场景?如果没有,我会在这里错过什么?
nservicebus - 无法在主节点中具有生产配置文件的分发器中启用超时管理器
将我的服务部署为具有生产配置文件的主服务器后,我看不到超时管理器在初始化中启用。我已经尝试了一切都没有成功。
我安装服务的方式是:
NServiceBus.Host.exe /install /serviceName:BusinessServices /displayName:BusinessServices /description:BusinessServices /userName:machinename\Administrator /password:pass
NServiceBus.Master nservicebus.production
端点配置是:
公共类 EndpointConfig : IConfigureThisEndpoint, AsA_Server,AsA_Publisher { }
配置是:
RavenDB 安装在该机器上,并且适用于 saga,无论如何在初始化中它说:
2014-05-19 17:02:55,428 [1] INFO NServiceBus.Configure [(null)] <(null)> - NServiceBus.IWantToRunBeforeConfiguration 的调用在 0.14 秒内完成 2014-05-19 17:02:55,785 [1] INFO NServiceBus.Configure [(null)] <(null)> - NServiceBus.Config.INeedInitialization 的调用在 0.00 秒内完成 2014-05-19 17:02:56,296 [1] INFO NServiceBus.Licensing.LicenseManager [(null)] <(null)> - 于 07/03/2014 00:00:00 2014-05-19 17:02:56,576 [1] INFO NServiceBus.Configure [(null)] <(null)> - 调用 NServiceBus。 INeedInitialization 在 0.79 秒内完成 2014-05-19 17:02:56,724 [1] INFO NServiceBus.Distributor.T5.BusinessServices.High [(null)] <(null)> - 端点配置为托管分发器,应用输入队列重新路由到 T5.BusinessServices.High。worker@WIN-74CD8F6BJ66 2014-05-19 17:02:57,118 [1] INFO NServiceBus.Configure [(null)] <(null)> - NServiceBus.IWantToRunBeforeConfigurationIsFinalized 的调用在 0.54 秒内完成 2014-05-19 17:02 :57,356 [1] INFO NServiceBus.Features.Sagas [(null)] <(null)> - 在扫描类型中找到 Sagas,启用 saga 持久性 2014-05-19 17:02:57,371 [1] INFO NServiceBus.Features.FeatureInitializer [(null)] <(null)> - 特征:审计 [4.6.1] - 启用自动订阅 [4.6.1] - 启用 BinarySerialization [4.6.1] - 由类别控制序列化程序 BsonSerialization [4.6.1] - 由类别控制序列化器 JsonSerialization [4.6.1] - 由序列化器类别控制 XmlSerialization [4.6.1] - 由序列化器类别控制 MsmqTransport [4.6.1] - 启用网关 [4.6.1] - 启用 TimeoutManager [4.6。1] - 禁用 Sagas [4.6.1] - 启用 SecondLevelRetries [4.6.1] - 启用 StorageDrivenPublisher [4.6.1] - 启用 MessageDrivenSubscriptions [4.6.1] - 启用 Heartbeats [1.0.0] - 启用 SagaAudit [1.0.0] - 启用
我还需要做些什么吗?
提前致谢
asp.net-mvc - 将 NServiceBus 升级到 4.6.1 后的配置问题
我遇到了一个有趣的错误。我已经升级了 Castle 和 NServiceBus。Castle 使用的是版本 3,现在使用的是版本 3.3.1。NServiceBus 使用的是 3.2.7,现在使用的是 4.6.1。
我的配置
我收到的错误是这样的:
组件 NServiceBus.Scheduling.ScheduledTaskMessageHandler 具有生活方式绑定,但它没有指定强制的“scopeRootSelector”。
如果有人知道我必须改变什么,请告诉我。我已尝试查看所有配置选项,但不确定我缺少什么。这是在 Web ui 和服务托管在两个不同位置的服务的 Web 界面上。Web UI 只从用户那里获取信息并发送消息以进行处理,没有预期的返回值。这就是我将其设置为 SendOnly 配置的原因。
更新:这是 Sean Farmar 要求的信息。
“/ClientServices”应用程序中的服务器错误。
组件 NServiceBus.Scheduling.ScheduledTaskMessageHandler 具有生活方式绑定,但它没有指定强制的“scopeRootSelector”。说明:执行当前 Web 请求期间发生未处理的异常。请查看堆栈跟踪以获取有关错误及其源自代码的位置的更多信息。
异常详细信息:Castle.MicroKernel.ComponentRegistrationException:组件 NServiceBus.Scheduling.ScheduledTaskMessageHandler 已绑定生活方式,但未指定强制“scopeRootSelector”。
源错误:
第 191 行:Configure.Serialization.Xml(); 第 192 行:第 193 行:Configure.With() 第 194 行:.CastleWindsorBuilder(container) 第 195 行:.UseTransport()
源文件:C:\ClientServices\trunk\src\UI\Global.asax.cs 行:193
堆栈跟踪:
[ComponentRegistrationException:组件 NServiceBus.Scheduling.ScheduledTaskMessageHandler 已绑定生活方式,但未指定强制的“scopeRootSelector”。] Castle.MicroKernel.DefaultKernel.CreateScopeAccessorForBoundLifestyle(ComponentModel 模型)+212 Castle.MicroKernel.DefaultKernel.CreateLifestyleManager(ComponentModel 模型,IComponentActivator 激活器) +182 Castle.MicroKernel.Handlers.DefaultHandler.InitDependencies() +148 Castle.MicroKernel.Handlers.AbstractHandler.Init(IKernelInternal kernel) +171 Castle.MicroKernel.Handlers.DefaultHandlerFactory.Create(ComponentModel 模型) +71 Castle.MicroKernel.DefaultKernel .Castle.MicroKernel.IKernelInternal.CreateHandler(ComponentModel model) +133 Castle.MicroKernel.DefaultKernel.AddCustomComponent(ComponentModel model) +50 Castle.MicroKernel.Registration。组件注册1.Castle.MicroKernel.Registration.IRegistration.Register(IKernelInternal kernel) +267
Castle.MicroKernel.DefaultKernel.Register(IRegistration[] registrations) +178
Castle.Windsor.WindsorContainer.Register(IRegistration[] registrations) +59
NServiceBus.ObjectBuilder.CastleWindsor.WindsorObjectBuilder.NServiceBus.ObjectBuilder.Common.IContainer.Configure(Type concreteComponent, DependencyLifecycle dependencyLifecycle) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\ObjectBuilder.CastleWindsor\WindsorObjectBuilder.cs:89
NServiceBus.ObjectBuilder.Common.CommonObjectBuilder.ConfigureComponent(Type concreteComponent, DependencyLifecycle instanceLifecycle) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\ObjectBuilder\Common\CommonObjectBuilder.cs:54
NServiceBus.Unicast.Config.ConfigUnicastBus.ConfigureMessageHandlersIn(IEnumerable
1 种)在 y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Unicast\Config\ConfigUnicastBus.cs:164 NServiceBus.Unicast.Config.ConfigUnicastBus.LoadMessageHandlers(IEnumerable 1 orderedTypes) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Unicast\Config\ConfigUnicastBus.cs:147
NServiceBus.Unicast.Config.ConfigUnicastBus.LoadMessageHandlers() in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Unicast\Config\ConfigUnicastBus.cs:98
NServiceBus.EnsureLoadMessageHandlersWasCalled.Init() in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\ConfigureUnicastBus.cs:49
NServiceBus.Configure.<Initialize>b__10(INeedInitialization t) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Configure.cs:350
NServiceBus.<>c__DisplayClass23
1.b__20(Type t) in y:\ BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Configure.cs:555 System.Collections.Generic.List 1.ForEach(Action
1 action) +11010045 NServiceBus.Configure.ForAllTypes(Action1 action) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Configure.cs:379
NServiceBus.Configure.ActivateAndInvoke(Action
y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Configure.cs:549 NServiceBus.Configure.Initialize() in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus 中的 1 个操作,可为 Nullable`1 thresholdForWarning)。 Core\Configure.cs:350 NServiceBus.ConfigureExtensions.SendOnly(Configure config) in y:\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Config\ConfigureExtensions.cs:18 Lsr.ClientServices.UI.NServiceBusInstaller.Install(IWindsorContainer容器,IConfigurationStore 存储)在 C:\ClientServices\trunk\src\UI\Global.asax.cs:193 Castle.Windsor.Installer.AssemblyInstaller.Install(IWindsorContainer 容器,IConfigurationStore 存储)+229 Castle.Windsor.WindsorContainer.Install( IWindsorInstaller[] 安装程序,DefaultComponentInstaller 范围)+165 Castle.Windsor.WindsorContainer。安装(IWindsorInstaller[] 安装程序)+227 Lsr.ClientServices.UI.MvcApplication.BootstrapContainer() 在 C:\ClientServices\trunk\src\UI\Global.asax.cs:52 Lsr.ClientServices.UI.MvcApplication.Application_Start()在 C:\ClientServices\trunk\src\UI\Global.asax.cs:44
asp.net-web-api - ravendb 上不存在超时索引
tl;博士:
- 我的 web api 服务运行缓慢,添加了日志记录
- 日志记录给了我关于无法找到超时的错误
- 没有看到服务器上webapi项目的ravendb数据库,但是开发机器有
- raven 在 8080 上运行并运行
- 尝试通过平台安装程序重新安装nservicebus(昨天从nservicebus下载)
- 仍然有同样的问题
- 我想我要么搞砸了部署,要么我需要以某种方式进行全新安装
- 为了让 webapi 项目读取超时,我需要做什么?
我试图让我们的应用程序在生产机器上运行以准备 alpha。
我们的应用程序有多个 web api 站点和许多服务主机。
我看到的错误目前仅在生产中的 web api 主机中:
这会重复一段时间。最终(大约 2 分钟)端点放弃并死了
我通过为 nservicebus 启用 log4net 文件附加程序来获取这些日志,以了解 Web api 服务发生了什么。
主机服务在我们的开发机器上运行良好,但出于某种原因,它们在生产机器上运行速度非常慢。我们在开发机器上看不到错误。我们在生产机器上安装了许可证,所以它不像我们受到过期许可证的限制。
奇怪的是,在我们的开发机器上,我们看到了我们的 web api 项目的数据库,但在生产机器上,只有安装的服务主机有数据库条目。
我们已经为这个特定的应用程序开发了大约 18 个月。可能是我们在安装 nservicebus 时,没有设置安装超时。但是,我尝试运行平台安装程序(昨天下载)并且超时仍然不存在。我假设当我安装服务主机时,超时会被安装,但由于某种原因它们没有出现。
在这一点上,我正在考虑卸载 nservicebus 和 ravendb,但我不确定如何进行干净的重新安装。
这是我的 global.asax 中的一些相关行
nservicebus4 - 在启动和停止总线时创建和删除 NServicebus 订阅
我的项目的设计简介包括以下内容:
能够随意启动 Windows 服务的新实例并将随机消息处理程序附加到每个实例,以便沿服务边界线对处理程序进行逻辑分组(或对处理程序进行分组的任何其他任意原因)。
我们选择的设计是将给定的消息类型及其所有处理程序封装到单个程序集 (DLL) 中。我试图在主机启动时生成订阅,并在主机停止时将它们从 Raven 中删除。
我在他们的创建中成功实现了特定消息类型程序集中的 IWantToRunWhenBusStartsAndStops 接口。IWantToRunWhenBusStartsAndStops.Start() 触发,我在那里添加了正确的订阅。
删除是我要解决的问题。IWantToRunWhenBusStartsAndStops.Stop() 方法仅在手动发出控制中断时调用。
我应该实施不同的界面还是应该采取不同的方法来解决问题?
在此先感谢您的帮助!
nservicebus - NServiceBus:传奇超时后存储队列中的消息数量增加
首先有关设置的一些信息:
- 我们正在运行 NServiceBus v4.6.3
- 分发器在具有集群队列的集群机器上运行。
- TimeoutManager 在工作人员上禁用,在分发服务器上启用。
我们正在经历什么
- 当处理 Saga-timeout 时,存储队列中的消息数会增加 1。
- 当消息被延迟时,存储队列中的消息数量会增加一。
我们知道什么
超时消息直接传送到特定的本地队列(在请求超时的服务器上),而不是集群队列。这绕过了常规路径,该路径涉及从存储队列中删除消息并将目标队列传递到工作线程。工作人员不知道这一点,并在处理超时消息后报告它已准备好处理新消息。
这种行为的原因是存储在 TimeoutData 中的目标队列被设置为工作器上的本地队列,而不是集群队列。这是一个例子:
我不确定我们遇到的是 NServiceBus 中的错误或配置错误。有人知道吗?
azure - 使用 Azure 服务总线传输的 NServicebus 中的事务
我在特定端点中有几个消息处理程序,它们针对 SQL Azure 数据库执行工作(目前仍在使用本地 SQL 2012 实例)。我有一个发布 2 个事件的命令处理程序,分别称为 X 和 Y。在同一个端点中,我有一个 X 的订阅者和一个 Y 的订阅者。这两个订阅者在内部使用相同的数据访问组件,称为 Z。注入是基于每次调用配置的,而不是共享的。
组件 Z 在幕后使用 Entity Framework 6。我遇到的问题是,仅打开数据库就会引发 SqlException 并抱怨 MSDTC 升级。
我暂时将处理程序包装在 TransactionScope.Suppress 中,这已经停止了错误,但我相信我错过了一些更基本的东西。
将端点配置为非事务性是否很简单?我原以为这会起作用,因为我已经配置为使用 Azure 服务总线作为传输机制。如果我这样做,如果在消息处理程序中引发异常,NServiceBus 仍会重试吗?(直到 SLR 限制——不是问题的一部分,我也理解幂等性问题)。