SOAP Timeout
-
I have an application that behaves as a SOAP server, using the ChannelServices::RegisterChannel and RemotingConfiguration::RegisterWellKnownServiceType calls. Although my SOAP service will not be called intensively by clients, it is still possible that it gets a burst of a few hundreds of calls at the same time. Problem is that the logic in the SOAP service typically take 5 to 10 seconds, and cannot be executed in parallel (complex mathematical calculations, results of one SOAP call may influence the results of later SOAP calls, it's a bit difficult to explain all the underlying details of it). In normal situations this is not a problem since the SOAP timeout is typically about 100 seconds. However, if I get a burst of 100 SOAP calls at the same time, some of them will get a timeout (which is acceptable). The real problem is that I cannot see in the server that the client has got a timeout, which means that the server will go on performing its calculations (or the calculations needed for the SOAP call will be queued) even if the client is not there anymore, and the results cannot be sent to it anymore. If I would be able to see that the client is not there anymore, I could abort the calculations, or I could remove the pending calculations from the queue again. I've looked in the .Net API but I haven't found a way yet to see if the client is still there or not. Is there an easy way to obtain this information? Or should I start to investigate asynchronously SOAP calls, or any other complex concept? Any code examples that might help? Thanks. Patje
Enjoy life, this is not a rehearsal !!!
-
I have an application that behaves as a SOAP server, using the ChannelServices::RegisterChannel and RemotingConfiguration::RegisterWellKnownServiceType calls. Although my SOAP service will not be called intensively by clients, it is still possible that it gets a burst of a few hundreds of calls at the same time. Problem is that the logic in the SOAP service typically take 5 to 10 seconds, and cannot be executed in parallel (complex mathematical calculations, results of one SOAP call may influence the results of later SOAP calls, it's a bit difficult to explain all the underlying details of it). In normal situations this is not a problem since the SOAP timeout is typically about 100 seconds. However, if I get a burst of 100 SOAP calls at the same time, some of them will get a timeout (which is acceptable). The real problem is that I cannot see in the server that the client has got a timeout, which means that the server will go on performing its calculations (or the calculations needed for the SOAP call will be queued) even if the client is not there anymore, and the results cannot be sent to it anymore. If I would be able to see that the client is not there anymore, I could abort the calculations, or I could remove the pending calculations from the queue again. I've looked in the .Net API but I haven't found a way yet to see if the client is still there or not. Is there an easy way to obtain this information? Or should I start to investigate asynchronously SOAP calls, or any other complex concept? Any code examples that might help? Thanks. Patje
Enjoy life, this is not a rehearsal !!!
I had a similar issue where I needed to calculate machine collision data on demand, which took a few seconds. This taking a few seconds means that the data doesnt need to be that fresh (as its going to take a while to calculate anyway). I'm assuming that if the client can be happy with a timeout on the call, then getting old data won't matter. If you want to just speed up the number of calls while still service relatively fresh data, stick your intensive calcuation in a block, and cache the results. Set your WCF service to multithreaded. Use Monitor.TryEnter to only allow one thread to enter the calculation code, and if the request isn't calculating (TryEnter returns false) then serve them the cached result of the last calculation. If you absolutely need everyones data, and its all sequential then they might just have to post data, get a sequence number, and retrieve their results in a second call. This would ensure you won't drop any data.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games. -
I had a similar issue where I needed to calculate machine collision data on demand, which took a few seconds. This taking a few seconds means that the data doesnt need to be that fresh (as its going to take a while to calculate anyway). I'm assuming that if the client can be happy with a timeout on the call, then getting old data won't matter. If you want to just speed up the number of calls while still service relatively fresh data, stick your intensive calcuation in a block, and cache the results. Set your WCF service to multithreaded. Use Monitor.TryEnter to only allow one thread to enter the calculation code, and if the request isn't calculating (TryEnter returns false) then serve them the cached result of the last calculation. If you absolutely need everyones data, and its all sequential then they might just have to post data, get a sequence number, and retrieve their results in a second call. This would ensure you won't drop any data.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.Thanks for the tip. I cannot use caching because every SOAP call is different, even if all the input arguments are the same (it's a kind of complex reservation system using mathematical formulas). I like the trick using the sequence number, but I would keep this as a last alternative. I was just hoping there would be a method to get from the .Net framework that the client has left (because of a time-out) before actually returning the result, but apparently, this isn't the case. Thanks for the tip anyway. Patje
Enjoy life, this is not a rehearsal !!!