如何实现 SoapHttpClientProtocol
由于 这个 问题告诉我 SoapHttpClientProtocol 不是线程安全的。而且，我的现实生活测试告诉我这是真的，因为我的 SoapHeader 属性在调用之间不断混淆。有没有办法确保我可以跨线程使用它并保持我的属性正确？并确保我不会遇到该问题中给出的示例，即一个线程认为连接已打开，而另一个线程已关闭它？发出请求后，我是否需要担心肥皂头值？在发出请求之前，如何验证属性是否与我设置的一致？
Since this question tells me that SoapHttpClientProtocol is not thread safe. And, my real life testing tells me this is true, as my SoapHeader properties keep getting mixed up between calls. Is there a way to make sure that I can use this across threads and keep my properties correct? And make sure I don't run into the example given in that question of one thread thinking the connection is open, when another thread has closed it? Do I need to worry about the soap header values after my request has been made? How can I verify the properties are as I set them until the request has been issued?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我要问的第一件事是，如果您不将其设为多线程，您的服务是否可以正常工作。如果您进行后续调用，它们是否都能正常工作并为您提供所需的结果？如果没有，那么服务器端很可能存在问题。
要查看您发送的内容，您可以在肥皂消息发送之前对其进行序列化。确保它正确生成。
我的工作阻止了对很多网站的访问，但如果我没记错的话，CodeProject 有一些示例。
如果单线程工作，请准备好序列化层，并让它在多线程场景中将文件写入磁盘。然后，您可以根据代码认为正在发送的内容来查看哪些内容有效，哪些内容无效。
您的呼叫很可能会被服务器混合，因为您尝试建立多个连接，而服务器可能会将您的端点视为一个值，有点像位于 NAT 防火墙后面。这意味着您可能正在获得连接，但您的其他线程之一首先获得了消息。如果是这种情况，您可以尝试在其自己的应用程序域中旋转每个线程，看看它是否为您做任何事情。并不是说它会起作用，但我不确定还有什么可供您尝试。
The first thing I would ask is does your service work correctly if you do not make it multi-threaded. If you make subsequent calls do they all work correctly and give you the desired results? If not then there is a problem on the server side more than likely.
To see what you are sending you could serialize down the soap message before it goes. Make sure it's getting generated correctly.
My job blocks access to a lot of websites but CodeProject has some examples if I remember correctly.
If the single thread works have the serialization layer in place and have it write the files to disk in your multi-threaded scenario. Then you can see what is working and what is not by what your code thinks it's sending.
More than likely your calls are getting mixed by the server since you are trying to establish multiple connections while it may be seeing your endpoint as one value, kind of like being behind a NAT firewall. Which means you may be getting a connection but one of your other threads gets its message through first. If that is the case you could try spinning each thread up in it's own app domain and see if it does anything for you. Not saying that it will work, but not sure off the top of my head what else may be available for you to try.