WCF中关于可靠会话的BUG!!
2010-04-27 13:12
921 查看
对WCF的可靠会话编程有一定了解的人应该知道,我们可以使用 DeliveryRequirementsAttribute 可以指示WCF确认绑定提供服务或客户端实现所需的功能。如果在从应用程序配置文件加载服务说明或在代码中以编程方式生成服务说明时检测到 DeliveryRequirementsAttribute 属性,则 WCF 会验证所配置的绑定,并支持该属性指定的所有功能。例如,您的服务可能要求绑定支持队列。使用 DeliveryRequirementsAttribute 可以让WCF 确认是否满足下列要求:
QueuedDeliveryRequirements 属性指定绑定必须满足的队列要求。
RequireOrderedDelivery 属性指示绑定是否必须支持有序消息传递。
TargetContract 属性指示要求所适用的类型。
但是,当你使用DeliveryRequirementsAttribute 特性的时候,会出现一些很奇怪的现象。经过我个人的分析,这是WCF的一个Bug。
现在,我通过下面的代码对服务进行寄宿,注意终结点绑定的可靠会话特性被开启,但是Ordered属性被设置成False。也就是该绑定不满足通过DeliveryRequirementsAttribute 设置的对有序消息交付的要求。
当上面的代码执行到ServiceHost开启(host.Open();),会抛出如下的异常。异常信息是“The DeliveryRequirementsAttribute on contract 'IOrderService' specifies a QueuedDeliveryRequirements value of NotAllowed. However, the configured binding for this contract specifies that it does support queued delivery. A queued binding may not be used with this contract.”翻译成中文就是“服务契约'IOrderService' 上的 DeliveryRequirementsAttribute 指定了 NotAllowed 的 QueuedDeliveryRequirements 值。但是,为此协定配置的绑定指定其不支持排队传送。排队绑定可能不能用于此契约”。实际上在这里QueuedDeliveryRequirements是Allowed,不应该出现如此的错误信息。
实际上,从名称就可能看出EnsureOrderedDeliveryRequirements方法是在验证终结点绑定的有序消息交付能,和队列消息传递一点关系都没有。通过Reflector,我们看看EnsureOrderedDeliveryRequirements方法的实现。
从上面的逻辑我们可以看到,如果“有序消息交付”验证失败会抛出InvalidOperationException异常,这和我们前面的StackTrace是一致的。而异常消息则定义在资源文件中。该资源文件的Key是“TheBindingForDoesnTSupportOrderedDelivery1”。为此,在此利用Reflector,看看资源项的定义,结果证实资源字符串的内容和上面抛出的异常消息是吻合的。所以,我们可以说由于WCF资源字符串的错误定义或者错误使用导致了这个Bug的产生。
QueuedDeliveryRequirements 属性指定绑定必须满足的队列要求。
RequireOrderedDelivery 属性指示绑定是否必须支持有序消息传递。
TargetContract 属性指示要求所适用的类型。
但是,当你使用DeliveryRequirementsAttribute 特性的时候,会出现一些很奇怪的现象。经过我个人的分析,这是WCF的一个Bug。
一、问题再现
我随便定义了一个简单的服务:OrderService。并在服务契约上应用了一个DeliveryRequirementsAttribute 特性,将RequireOrderedDelivery和QueuedDeliveryRequirements分别设置成TRUE和QueuedDeliveryRequirementsMode.Allowed,也就是允许终结点的绑定采用队列传递,但是要求绑定采用有序消息交付。[Serializable] public class Order { } [ServiceContract] [DeliveryRequirements(RequireOrderedDelivery = true, QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.Allowed )] public interface IOrderService { [OperationContract] void ProcessOrder(Order order); } public class OrderService : IOrderService { public void ProcessOrder(Order order) { throw new NotImplementedException(); } }
现在,我通过下面的代码对服务进行寄宿,注意终结点绑定的可靠会话特性被开启,但是Ordered属性被设置成False。也就是该绑定不满足通过DeliveryRequirementsAttribute 设置的对有序消息交付的要求。
class Program { static void Main(string[] args) { using (ServiceHost host = new ServiceHost(typeof(OrderService))) { WSHttpBinding binding = new WSHttpBinding(SecurityMode.Message, true); binding.ReliableSession.Ordered = false; host.AddServiceEndpoint(typeof(IOrderService), binding, "http://127.0.0.1:3721/orderservice"); host.Open(); Console.Read(); } } }
当上面的代码执行到ServiceHost开启(host.Open();),会抛出如下的异常。异常信息是“The DeliveryRequirementsAttribute on contract 'IOrderService' specifies a QueuedDeliveryRequirements value of NotAllowed. However, the configured binding for this contract specifies that it does support queued delivery. A queued binding may not be used with this contract.”翻译成中文就是“服务契约'IOrderService' 上的 DeliveryRequirementsAttribute 指定了 NotAllowed 的 QueuedDeliveryRequirements 值。但是,为此协定配置的绑定指定其不支持排队传送。排队绑定可能不能用于此契约”。实际上在这里QueuedDeliveryRequirements是Allowed,不应该出现如此的错误信息。
二、资源的错误定义导致异常消息不正确
我们对上面抛出的异常进行进一步地追踪,你会现在该异常的StackTrace如下。可以看出来,异常是在执行DeliveryRequirementsAttribute 的EnsureOrderedDeliveryRequirements方法时抛出来的。at System.ServiceModel.DeliveryRequirementsAttribute.EnsureOrderedDeliveryRequirements(String name, Binding binding) at System.ServiceModel.DeliveryRequirementsAttribute.ValidateEndpoint(ServiceEndpoint endpoint) at System.ServiceModel.DeliveryRequirementsAttribute.System.ServiceModel.Description.IContractBehavior.Validate(ContractDescription description, ServiceEndpoint endpoint) at System.ServiceModel.Description.ServiceEndpoint.Validate(Boolean runOperationValidators, Boolean isForService) at System.ServiceModel.Description.DispatcherBuilder.ValidateDescription(ServiceDescription description, ServiceHostBase serviceHost) at System.ServiceModel.Description.DispatcherBuilder.InitializeServiceHost(ServiceDescription description, ServiceHostBase serviceHost) at System.ServiceModel.ServiceHostBase.InitializeRuntime() at System.ServiceModel.ServiceHostBase.OnBeginOpen() at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open() at ConsoleApplication4.Program.Main(String[] args) in D:\Users\jinnan\Documents\Visual Studio 2008\Projects\ConsoleApplication4\ConsoleApplication4\Program.cs:line 23 at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()
实际上,从名称就可能看出EnsureOrderedDeliveryRequirements方法是在验证终结点绑定的有序消息交付能,和队列消息传递一点关系都没有。通过Reflector,我们看看EnsureOrderedDeliveryRequirements方法的实现。
private void EnsureOrderedDeliveryRequirements(string name, Binding binding) { if (this.RequireOrderedDelivery) { IBindingDeliveryCapabilities property = binding.GetProperty<IBindingDeliveryCapabilities>(new BindingParameterCollection()); if (property == null) { throw DiagnosticUtility.ExceptionUtility.ThrowHelperError(new InvalidOperationException(SR.GetString("SinceTheBindingForDoesnTSupportIBindingCapabilities1_1", new object[] { name }))); } if (!property.AssuresOrderedDelivery) { throw DiagnosticUtility.ExceptionUtility.ThrowHelperError(new InvalidOperationException(SR.GetString("TheBindingForDoesnTSupportOrderedDelivery1", new object[] { name }))); } } }
从上面的逻辑我们可以看到,如果“有序消息交付”验证失败会抛出InvalidOperationException异常,这和我们前面的StackTrace是一致的。而异常消息则定义在资源文件中。该资源文件的Key是“TheBindingForDoesnTSupportOrderedDelivery1”。为此,在此利用Reflector,看看资源项的定义,结果证实资源字符串的内容和上面抛出的异常消息是吻合的。所以,我们可以说由于WCF资源字符串的错误定义或者错误使用导致了这个Bug的产生。
相关文章推荐
- 关于WCF的会话问题
- 深入剖析WCF的可靠会话
- 快速入门系列--WCF--06并发限流、可靠会话和队列服务
- 使命必达: 深入剖析WCF的可靠会话[原理揭秘篇](下)
- WCF学习笔记之可靠会话
- WCF把书读薄(4)——事务编程与可靠会话
- 一起谈.NET技术,使命必达:深入剖析WCF的可靠会话
- WCF 可靠会话
- “深入剖析WCF的可靠会话”系列[共8篇]
- 深入剖析WCF的可靠会话[实例篇](内含美女图片,定力差者慎入)
- WCF中的可靠会话(reliableSession)中的inactivityTimeout和receiveTimeout
- 使命必达: 深入剖析WCF的可靠会话[协议篇](上)
- 使命必达: 深入剖析WCF的可靠会话[协议篇](下)
- 关于WCF的InstanceContextMode,与会话相关
- 使命必达: 深入剖析WCF的可靠会话[概念篇]
- 关于WCF的一个非常“无语”的BUG!
- wcf 远程终结点已终止该序列 可靠会话出错
- 使命必达: 深入剖析WCF的可靠会话[原理揭秘篇](上)
- 使命必达: 深入剖析WCF的可靠会话[编程篇](下)
- 使命必达: 深入剖析WCF的可靠会话[共8篇]