views:

18

answers:

1

Hi,

When making calls to a webservice from an asp.net web application, to avoid creating a new proxy for each webservice call, I store the proxy in a dictonary. So when a call to the webservice is being made, an instance of the webservice proxy is returned based on a key passed to a factory method. If a proxy for the corresponding key is already created, that proxy is returned. Otherwise, it creates a proxy for the key and returns the proxy.

This all works fine, unless the actual webservice for some reason "goes down" and don't return any response. If that happens, which it in my case does pretty frequently, a System.Net.HttpWebRequest is created, which never gets collected by the GC. The reason is, the HttpWebRequest is a local variable in HttpWebRequest.GetResponse() which is still being executed (since it is waiting for a response that will never come). Hence, there exist a reference to HttpWebRequest that will keep the object alive.

One way to get around this would be to put the call to the webservice within a Using block, thereby disposing the object after the call has been made. That way, the references to the HttpWebRequest would be cut off so that the HttpWebRequest can be collected by the GC. However, by disposing the proxy, the whole idea of storing the proxy in a dictonary to avoid creating a proxy for each call malfunctions.

Hence, my question is, do anyone have any idea how I could do to solve the issue having references to the HttpWebRequests left when there is no response from the webservice?

Thanx in advance!

Some psuedo-code to explain the concept of storing the proxies in a dictonary:

public Proxy GetProxy(String key) {
            if(!proxies.ContainsKey(key)) {
                proxies[key] = new Proxy();
            }
            return proxies[key];
        }

public Object GetObject(String key) {
            Object object =
            this.GetProxy(key).GetObject();
            return object;
        }
+1  A: 

If the target site goes down, you'll likely get a HttpException. Can you leverage that mechanism for managing the lifetime of your instances?

Matthew Abbott