问题描述
|
我现在在项目中工作,在该项目中,应该使用服务器代理功能将多个POS同步到主服务器。现在,我为该解决方案准备错误处理,并希望向客户展示它的工作方式。这意味着我将为每种错误准备测试脚本,然后客户端在测试POS上运行它以查看错误是否得到正确处理。
我们将使用带毒害消息= OFF的sql Server 2008R2。
消息类型= XML(但内部可以是不同类型的数据,某些节点将包含BLOB)。
POS将位于圆孔之外,因此将确保传输安全(但不进行对话加密)。
我将错误分为几个子组:
逻辑错误(例如,字符串)
数)。它将由处理
服务器端的TRY-CATCH块是
容易模拟
Service broker配置错误
(消息或将不会退回,或者
无法到达目的地)。我认为
可以使用sql处理
服务器服务代理事件和
模拟会有些“不好”
配置\”(SB GUID,服务名称
等等)
运输错误。这是当我们
有一个坏消息。实际上是
客户意见来测试这种
错误。我不知道我们是否有
保证运输水平
(证书)我们受到保护
这种错误。另一个问题
我该如何模拟这一点。
问题:
还有其他错误类型吗?
描述的#2错误处理逻辑足够好吗?
如何处理和模拟#3?
解决方法
我在本文的第二部分将讨论Service Broker错误,错误的发生方式以及如何处理它们。对您来说重要的是区分两类错误:
可恢复:传输问题,大多数配置错误(如路由错误),服务器无法访问。所有这些将不会导致SSB错误,而是会导致延迟。消息将保留在transmission_queue中,期望该问题是暂时的并且可以解决,包括一些配置问题。解决问题后,SSB将重试并发送邮件。
不可恢复:这些是SSB认为不可恢复的问题,例如。错误的消息格式。在这种情况下,会话将中止,并且两个端点都将收到错误消息。
我还有一篇文章Service Broker过程中的错误处理,讨论了SSB激活的上下文中异常处理的一些特定主题。
最后一点:我强烈建议您不要关闭有毒消息检测功能。最好是禁用处理,而不是因为有毒消息而旋转无进展的ad-nauseam。
正如关于如何模拟损坏的消息的主题:难以模拟(您可以尝试设置端口转发器,让所有流量通过,但随机破坏其中的一些流量)却毫无意义。即使是明文形式的所有SSB通信,也都经过加密签名,由于消息签名验证失败,任何消息损坏都将导致突然断开连接。