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?
+1
A:
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.
Joshua Cauble
2009-12-23 17:07:21
Yes, single threaded works just fine. That's the code running right now, I was trying to speed up the work. The other two suggestions I will try both writing the calls out and trying the app domain. Thanks.
Alex
2009-12-23 17:28:47
Another thought for testing to see if it's you or them. Create a simple exe (console based is fine) that just keeps hitting the service. Create two versions, say for two different request types. Check your response against what you know you should get and run both exes at the same time. It should loop and keep resending so as to create volume and hopefully repeat your problem. Have it fail out if it gets a bad response. May help to eliminate some avenues. Also, if it works then maybe the app domain thing might as well or there is something in your code causing the corruption.
Joshua Cauble
2009-12-23 18:05:06
thanks for the help on figuring it out. It is definetly on the server side now that I can actually see my soap messages and examine them. Didnt get my problem fixed, but now I know to figure otu a work around rather than a fix.
Alex
2010-01-07 13:09:08
Glad I could help. Too bad it's on there side it's always hard to get third parties to update stuff.
Joshua Cauble
2010-01-07 20:24:26