Transport Error - code 12152

[dleung]

Getting this transport error sporadically. I looked up the code and found the follow:

  12152       ERROR_HTTP_INVALID_SERVER_RESPONSE
               The server response could not be parsed.

Full error note is:

Transport Error - HTML Code 12152 for URL:
http://<server>.../isomorphic/IDACall

Any general explanations as to what could be causing it?

-d

[Isomorphic]

Hi DLeung,

What do you see in the server-side logs when this error occurs?

[dleung]

Unfortunately this has only happened sporadically and was reported by a client. Which is why I was hoping maybe there would be a generic explanation. I understand it would be difficult to troubleshoot without much more but thought I'd give you guys a shot.

-d

[Isomorphic]

Hi DLeung,

A possible approach, that has worked for similarly intermittent problems we've run into, is to search the server side logs for "Exception" and try to find something from the general time that the customer reported the issue.

And actually there is one possible cause we can name. Sometimes firewalls are configured to sever any open HTTP connections that are older than 1 or 2 minutes, as a security heuristic.

[Isomorphic]

After subsequent investigation, it looks like all HTTP 12xxx error codes, including 12152 and 12030, are bogus, IE6-specific errors that can happen with some brands of HTTP proxy when proxying HTTPS requests.

It appears to be safe and correct to simply resend the failed HTTP request. In SmartClient, you can do this by providing an implementation of RPCManager.handleError() that calls RPCManager.resendTransaction() when the RPCResponse.httpResponseCode is in the 12xxx range.

[mvarvil]

Status

We're getting a steady trickle of these HTTP 12xxx response codes being reported.

Since this post was from Jan, 2008, I first wanted to check if the 6.5 release already attempts to handle the HTTP 12xxx error codes or if we still need resend the transaction ourselves. (See the last isomorphic post below)

If we still need to tackle this ourselves, it seems to make sense to overrride RPCManager.handleError() and resend the transaction; as long as we call Super(). Right?

Thanks,
Mark Varvil

[Isomorphic]

Hi Mark,

We haven't tried rolling this into SmartClient because we don't have an environment where we can reproduce these errors. Some info about your setup (brand of webserver, proxies involved, etc) might make it possible to reproduce the problem.

In the meantime, yes, overriding handleError (note it's a class method, so use addClassProperties) is the right approach, and do call Super. Please let us know if this banishes the error for you.

[mvarvil]

I'll implement the retry logic and see if the reported issues decrease. It's not reproducable in any environment.

While reading about IE's 12xxx error codes, I found the link below interesting.

Do you see anything in the posts by "DragonLaird" that might help us and SmartClient with these 12xxx errors?

http://www.perkiset.org/forum/ajax/xmlhttprequest_ie6_ssl_and_12030_error_what_is_the_solution-t442.0.html

[Isomorphic]

That's one of several we've seen with speculative solutions that some users confirm and others cast doubt on. If we see a Microsoft Knowledge Base article stating the cause and the workaround, we'll implement it :) Until then workarounds like Dragonlaird's could cause more harm than good, especially with no way to actually reproduce the issue.

[mvarvil]

Calling Super after overriding handleError results in the error below. Am I doing this incorrectly?

15:39:22.611:XRP5:WARN:Log:Call to Super for method: handleError failed on: [Class RPCManager]: couldn't find a superclass implementation of : RPCManager.handleError [Stack trace logged via Firebug: FBugTrace0]

if (isc.RPCManager) {
    isc.RPCManager.addClassProperties({
        handleError: function (response, request) {
            Log.logWarn("httpResponseCode:  " + response.httpResponseCode);
            Log.logWarn("response.transactionNum:  " + response.transactionNum);
            if (response.httpResponseCode >=12000 && response.httpResponseCode <=12174) {
                    Log.logWarn("Resending request due to httpResponseCode of " + response.httpResponseCode);
                    RPCManager.clearTransaction(response.transactionNum);
                        RPCManager.resendTransaction(response.transactionNum);
                    return;
            }

            if (response.httpResponseCode == 503) {
                Log.logWarn("Resending request due to httpResponseCode of " + response.httpResponseCode);
                    RPCManager.clearTransaction(response.transactionNum);
                RPCManager.resendTransaction(response.transactionNum);
                return;
            }

            this.Super("handleError", response, request);
        }
    });

[Isomorphic]

Hi Mark,

Your Super call should look like:

this.Super("handleError", arguments);

[mvarvil]

Yes using the arguments arg is correct, but still no Super handleError exists...

Are you SURE we can override the static Class method "handleError" and then be able to call Super on it? There isn't a Super for it to call is there?

[mvarvil]

Following up today with code snippet per your recomendation to call Super.

How can we override RPCManager.handleError() and still call Super on it so that we don't lose your default error handling?

These calls don't work, as I suspect there is NO super handleError to call:

1) this.Super("handleError", arguments);
2) RPCManager.Super("handleError", arguments):

Thanks,
Mark

Hi Mark,

We haven't tried rolling this into SmartClient because we don't have an environment where we can reproduce these errors. Some info about your setup (brand of webserver, proxies involved, etc) might make it possible to reproduce the problem.

In the meantime, yes, overriding handleError (note it's a class method, so use addClassProperties) is the right approach, and do call Super. Please let us know if this banishes the error for you.

if (isc.RPCManager) {
    isc.RPCManager.addClassProperties({
        handleError: function (response, request) {
            Log.logWarn("httpResponseCode:  " + response.httpResponseCode);
            Log.logWarn("response.transactionNum:  " + response.transactionNum);
            if (response.httpResponseCode >=12000 && response.httpResponseCode <=12174) {
                    Log.logWarn("Resending request due to httpResponseCode of " + response.httpResponseCode);
                    RPCManager.clearTransaction(response.transactionNum);
                    RPCManager.resendTransaction(response.transactionNum);
                    return;
            }

            if (response.httpResponseCode == 503) {
                Log.logWarn("Resending request due to httpResponseCode of " + response.httpResponseCode);
                    RPCManager.clearTransaction(response.transactionNum);
                    RPCManager.resendTransaction(response.transactionNum);

                return;
            }
            
            // Want to Invoke default (Super)  handleError() here...

        }
    });
}

[Isomorphic]

Hi Mark,

SmartClient supports inheritance and calling Super for class methods, however, this works when creating a subclass of another class, and here there is no subclass, there's simply a method being replaced in the existing class. Sorry for the confusion on this point.

For this specific method we'd recommend just not calling Super(). You can effectively do what the default handleError() is doing by just using isc.warn(response.data) if response.data is a String, and isc.warn(response.status) if not.

[mvarvil]

Understood; we had actually thought about doing just that... But where is your relogin logic handled? If it's in RPCManager.handleError(), we would lose that functionality.

Can you confirm that we won't lose SmartClient goodness such as relogin if we proceed with your suggestion?

Also, when we resend the transaction, it appears that SmartClient will only resend an transaction 1 time. I judge this as a fine trait, for we don't want to end up in an endless fetch loop. Can you also confirm for us that resendTransaction only retries once? If this is not simply "working as designed", then we need to investigate further to understand the process.

Thanks,
Mark Varvil