Question

I have a custom Sharepoint 2010 web part that runs the user through a series of steps in a registration process. At each step, when whatever required input is completed, the user clicks the Continue button which is a standard server side button control. The code behind does some validation and DB updates before calling Response.Redirect which refreshes the same page with updated session data.

(Note: the session data is kept in the URL as an encrypted query string parameter, not by the conventional Session object)

This solution works fine in my single server test environment, but as soon as I deploy it to a load balanced stage or production environment some requests simply time out without receiving a response after clicking Continue (ERR_TIMED_OUT).

1. The Webpart log shows that the webpart is in fact calling Response.Redirect with a valid URL
2. This is no server resource issue. The timeout can be set to a minute or more, no response is received.
3. Only happens when deployed to load balanced servers
4. Everything works fine when I complete a registration on one of the load balanced servers – which leads me to believe there is a problem with load balancing and server sessions. I know that when interacting with a load balanced web application from one of the server nodes in the NLB, all requests will go to that particular server.

I know I have faced a similar issue before, but it is several years ago and I cannot remember what the solution was.

        try
        {
            // get clean URL without query string parameters
            string url;
            if (string.IsNullOrEmpty(Request.Url.Query))
                url = Request.Url.AbsoluteUri;
            else
                url = Request.Url.AbsoluteUri.Replace(Request.Url.Query, "");

            // add encrypted serialized session object
            url += "?" + Constants.QueryStringParameterData + "=" + SessionData.Serialize(true);

            _log.Info("Redirecting to url '" + url + "'..");
            Response.Redirect(url);
        }
        catch (Exception) { }

Answer 1

OK, the problem has been resolved.

It turned out to be UAG that was doing something in the background, and the way I discovered it was that the links that triggered the postbacks got changed from

http://some_url.com/sites/work/al2343/page.aspx

to

http://some_other_url.domain.com/uniquesigfed6a45cdc95e5fa9aa451d1a37451068d36e625ec2be5d4bc00f965ebc6a721/uniquesig1/sites/work/al2343/page.aspx

(Take note of the “uniquesig” in there)

This was the URL the browser actually tried to redirect to, but because of whatever the issue was with UAG the navigation froze.

I don’t know how they fixed it, but at least the problem was not in my component.