[Isomorphic]

Relogin is unrelated and will be preserved. Relogin is in a sense a "meta-error" - it isn't necessary formatted like other errors - and for that reason goes through special handling (loginRequired() entry point).

There isn't actually logic to allow transactions to be resent only once and we wouldn't really want to do that - it makes sense to periodically retry a failed connection, for example. It looks like your code is actually hitting this behavior by happenstance - it's invalid to call resendTransaction() after you've called clearTransaction(), because the behavior of clearTransaction is to:

Erase all client-side record of a transaction, such that any response from the server will be ignored.

Your code may be appearing to work because the behavior of resendTransaction() when a non-existant id is passed would be to resend the last transaction.

Most likely you want to get rid of the call to clearTransaction(), retain the call to resendTransaction(), and put in logic to retry no more than a few times, perhaps with brief delays (since we don't really know why IE throws this error) and then finally give up and isc.warn() the user about the problem or perhaps capture additional information and log it where the user can provide it to support.

[mvarvil]

We are NOT seeing the described behavior you describe for using the resendTransaction.

There isn't actually logic to allow transactions to be resent only once

put in logic to retry no more than a few times

To test this scenario, we have a non-queued fetch occurring at the press of a button. We should expect an endless-fetch-loop, as the response is coded to always serve a 503 response.

The first fetch receives a 503 error and resendTransaction() is invoked. This 2nd request also receives a 503. The error logic is again invoked and resendTransaction() is invoked a 3rd time, but no request goes outbound for this 3rd request, as evidenced by the console window, firebug, and the server log.

Now, when the button is clicked again, new behavior appears. We get a 503 response from the 1st fetch and the error handler calls resendTransaction() but now the 2nd request doesn't go outbound.

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

            if (response.httpResponseCode == 503) {
                Log.logWarn("Resending request #" + response.transactionNum  + " due to httpResponseCode of " + response.httpResponseCode);
//                isc.Class.delayCall("resendTransaction", [response.transactionNum], 500);
                RPCManager.resendTransaction(response.transactionNum);
                return;
            }

            if (response.data instanceof String || typeof response.data == 'string') {
                isc.warn(response.data);
            } else {
                isc.warn(response.status);
            }

        }
    });
}

[mvarvil]

LOG Statements:

12:59:31.180:MUP0:DEBUG:RouteSearchModule:calling listgrid.fetchdata()
12:59:31.190:MUP0:INFO:ResultSet:isc_ResultSet_222:setCriteria: filter criteria unchanged
12:59:31.202:MUP0:INFO:ResultSet:isc_ResultSet_222:sortByProperty(DiscoveryTime, undefined): invalidating cache
12:59:31.210:MUP0:INFO:ResultSet:isc_ResultSet_222:Invalidating cache
12:59:31.219:MUP0:DEBUG:ResultSet:isc_ResultSet_222:getRange(0,1), cache check: 0,50 firstMissingRow: 0 lastMissingRow: 50
12:59:31.227:MUP0:DEBUG:ResultSet:isc_ResultSet_222:getRange: guessing forward scrolling
12:59:31.235:MUP0:INFO:ResultSet:isc_ResultSet_222:getRange(0, 1) will fetch from 0 to 100
12:59:31.245:MUP0:INFO:ResultSet:isc_ResultSet_222:fetching rows 0,100 from server
12:59:31.255:MUP0:DEBUG:RPCManager:Grabbed prompt from first request that defined one: Finding records that match your criteria...
12:59:31.265:MUP0:INFO:RPCManager:sendQueue[6]: 1 RPCRequest(s); transport: xmlHttpRequest; target: ./smartclientRPC.do?isc_rpc=1&isc_v=6.5&isc_xhr=1&isc_tnum=6
12:59:31.279:MUP0:DEBUG:RPCManager:XMLHttpRequest POST to ./smartclientRPC.do?isc_rpc=1&isc_v=6.5&isc_xhr=1&isc_tnum=6 contentType: application/x-www-form-urlencoded; charset=UTF-8 with body -->_transaction=<transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:type="xsd:Object"><transactionNum xsi:type="xsd:long">6</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object"><criteria xsi:type="xsd:Object"><searchType>0</searchType></criteria><operationConfig xsi:type="xsd:Object"><dataSource>arrivedFiles_DS</dataSource><operationType>fetch</operationType></operationConfig><startRow xsi:type="xsd:long">0</startRow><endRow xsi:type="xsd:long">100</endRow><sortBy>-DiscoveryTime</sortBy><appID>builtinApplication</appID><operation>arrivedFiles_DS_fetch</operation><oldValues xsi:type="xsd:Object"><searchType>0</searchType></oldValues></elem></operations></transaction>&protocolVersion=1.0<--
12:59:31.396:MUP0[E]:INFO:ResultSet:isc_ResultSet_222:sortByProperty(DiscoveryTime, false): invalidating cache
12:59:31.407:MUP0[E]:INFO:ResultSet:isc_ResultSet_222:Invalidating cache
12:59:31.585:MUP0[E]:DEBUG:ResultSet:isc_ResultSet_222:getRange(0,34), cache check: 0,66 firstMissingRow: 0 lastMissingRow: 66
12:59:31.600:MUP0[E]:DEBUG:ResultSet:isc_ResultSet_222:getRange: guessing forward scrolling
12:59:31.614:MUP0[E]:INFO:ResultSet:isc_ResultSet_222:getRange(0, 34) will fetch from 0 to 100
12:59:31.777:RDQ2:DEBUG:ResultSet:isc_ResultSet_222:getRange(0,32), cache check: 0,65 firstMissingRow: 0 lastMissingRow: 65
12:59:31.790:RDQ2:DEBUG:ResultSet:isc_ResultSet_222:getRange: guessing forward scrolling
12:59:31.801:RDQ2:INFO:ResultSet:isc_ResultSet_222:getRange(0, 32) will fetch from 0 to 100
12:59:31.891:XRP5:INFO:RPCManager:transaction 6 arrived after 615ms
12:59:31.904:XRP5:DEBUG:RPCManager:RPC request to: ./smartclientRPC.do returned with http response code: 503. Response text:
<html><head><title>Apache Tomcat/6.0.16 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 503 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested service () is not currently available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.16</h3></body></html>
12:59:31.919:XRP5:DEBUG:RPCManager:Result string for transaction 6: [
{data: "Transport error - HTTP code: 503 for URL..."[61],
status: -90}
]
12:59:31.933:XRP5:INFO:RPCManager:rpcResponse(arrivedFiles_DS_fetch)[fetch]: result: object[status=-90]
12:59:31.946:XRP5:INFO:ResultSet:isc_ResultSet_222:Received 0 records from server
12:59:31.959:XRP5:DEBUG:ResultSet:isc_ResultSet_222:full length set to: 0
12:59:31.973:XRP5:DEBUG:ResultSet:isc_ResultSet_222:integrating 0 rows into cache at position 0
12:59:31.986:XRP5:INFO:ResultSet:isc_ResultSet_222:cached 0 rows, from 0 to 0 (0 total rows, 0 cached)
12:59:32.000:XRP5:INFO:ResultSet:isc_ResultSet_222:Cache for current criteria complete
12:59:32.013:XRP5:INFO:ResultSet:isc_ResultSet_222:sortByProperty(DiscoveryTime, false): full cache allows local sort
12:59:32.028:XRP5:WARN:Log:Received httpResponseCode(503) for transactionNumber:  6
12:59:32.043:XRP5:WARN:Log:Response Object: {operationId: "arrivedFiles_DS_fetch",
clientContext: Obj,
context: Obj,
transactionNum: 6,
httpResponseCode: 503,
httpResponseText: "<html><head><title>Apache Tomcat/6.0.16 ..."[961],
xmlHttpRequest: [object XMLHttpRequest],
transport: "xmlHttpRequest",
clientOnly: undef,
isStructured: true,
callbackArgs: null,
results: Obj,
status: -90,
data: "Transport error - HTTP code: 503 for URL..."[61],
startRow: 0,
endRow: 0,
totalRows: 0}
12:59:32.060:XRP5:WARN:Log:Resending request #6 due to httpResponseCode of 503
12:59:32.187:TMR2:INFO:ResultSet:isc_ResultSet_222:fetching rows 0,100 from server
12:59:32.206:TMR2:DEBUG:RPCManager:Grabbed prompt from first request that defined one: Finding records that match your criteria...
12:59:32.225:TMR2:INFO:RPCManager:sendQueue[7]: 1 RPCRequest(s); transport: xmlHttpRequest; target: ./smartclientRPC.do?isc_rpc=1&isc_v=6.5&isc_xhr=1&isc_tnum=7
12:59:32.246:TMR2:DEBUG:RPCManager:XMLHttpRequest POST to ./smartclientRPC.do?isc_rpc=1&isc_v=6.5&isc_xhr=1&isc_tnum=7 contentType: application/x-www-form-urlencoded; charset=UTF-8 with body -->_transaction=<transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:type="xsd:Object"><transactionNum xsi:type="xsd:long">7</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object"><criteria xsi:type="xsd:Object"><searchType>0</searchType></criteria><operationConfig xsi:type="xsd:Object"><dataSource>arrivedFiles_DS</dataSource><operationType>fetch</operationType></operationConfig><startRow xsi:type="xsd:long">0</startRow><endRow xsi:type="xsd:long">100</endRow><sortBy>-DiscoveryTime</sortBy><appID>builtinApplication</appID><operation>arrivedFiles_DS_fetch</operation><oldValues xsi:type="xsd:Object"><searchType>0</searchType></oldValues></elem></operations></transaction>&protocolVersion=1.0<--
12:59:32.282:RDQ4:DEBUG:ResultSet:isc_ResultSet_222:getRange(0, 0): returning empty list
12:59:32.403:XRP2:INFO:RPCManager:transaction 7 arrived after 160ms
12:59:32.423:XRP2:DEBUG:RPCManager:RPC request to: ./smartclientRPC.do returned with http response code: 503. Response text:
<html><head><title>Apache Tomcat/6.0.16 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 503 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested service () is not currently available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.16</h3></body></html>
12:59:32.442:XRP2:DEBUG:RPCManager:Result string for transaction 7: [
{data: "Transport error - HTTP code: 503 for URL..."[61],
status: -90}
]
12:59:32.463:XRP2:INFO:RPCManager:rpcResponse(arrivedFiles_DS_fetch)[fetch]: result: object[status=-90]
12:59:32.484:XRP2:INFO:ResultSet:isc_ResultSet_222:Received 0 records from server
12:59:32.510:XRP2:DEBUG:ResultSet:isc_ResultSet_222:full length set to: 0
12:59:32.537:XRP2:DEBUG:ResultSet:isc_ResultSet_222:integrating 0 rows into cache at position 0
12:59:32.563:XRP2:INFO:ResultSet:isc_ResultSet_222:cached 0 rows, from 0 to 0 (0 total rows, 0 cached)
12:59:32.594:XRP2:INFO:ResultSet:isc_ResultSet_222:Cache for current criteria complete
12:59:32.620:XRP2:INFO:ResultSet:isc_ResultSet_222:sortByProperty(DiscoveryTime, false): full cache allows local sort
12:59:32.644:XRP2:WARN:Log:Received httpResponseCode(503) for transactionNumber:  7
12:59:32.667:XRP2:WARN:Log:Response Object: {operationId: "arrivedFiles_DS_fetch",
clientContext: Obj,
context: Obj,
transactionNum: 7,
httpResponseCode: 503,
httpResponseText: "<html><head><title>Apache Tomcat/6.0.16 ..."[961],
xmlHttpRequest: [object XMLHttpRequest],
transport: "xmlHttpRequest",
clientOnly: undef,
isStructured: true,
callbackArgs: null,
results: Obj,
status: -90,
data: "Transport error - HTTP code: 503 for URL..."[61],
startRow: 0,
endRow: 0,
totalRows: 0}
12:59:32.690:XRP2:WARN:Log:Resending request #7 due to httpResponseCode of 503
12:59:32.728:RDQ4:DEBUG:ResultSet:isc_ResultSet_222:getRange(0, 0): returning empty list

[Isomorphic]

Hi Mark,

This looks like an interaction between the ResultSet's default behavior and your handleError() code and/or other custom code that's in the loop. For example, if you have code in dataArrived(), it will actually fire in this situation.

Have you tried this with a direct call to DataSource.fetchData(), and nothing else?

Meanwhile we're still looking at whether there's a bug here - possibly something related to using willHandleError with resendTransaction().

[mvarvil]

Have you tried this with a direct call to DataSource.fetchData(), and nothing else?

I tested this for you, and the same behavior exists whether using a datasource.fetchData() or listGrid.fetchData() when the button is clicked.

For example, if you have code in dataArrived()...

We aren't using dataArrived() or anything fancy.

Hope this helps.

-- Mark

[Isomorphic]

Hi Mark,

You must call suspendTransaction() before resendTransaction(). This wasn't adequately doc'd in 6.5.1 as the only use case really covered was relogin, where suspendTransaction() is called for you.

suspendTransaction() is what cancels all further processing of the transaction, and critically, ensures that it does not reach the end of processing where it is automatically clear()d (because it's done), which was the reason you couldn't resend it again.

We're adding some more docs to clarify this (as well as better warning messages).

Here's a simple sample but bear in mind this will go into an infinite request loop:

isc.RPCManager.addClassProperties({
    handleError : function (response, request) {
        isc.logWarn("got response: " + isc.echoAll(response));
        if (response.httpResponseCode==404) {
            isc.logWarn("resending transaction: " + response.transactionNum);
            isc.RPCManager.suspendTransaction(response.transactionNum);
            isc.RPCManager.resendTransaction(response.transactionNum);
        }
    }
})

isc.RPCManager.sendRequest({
    actionURL:"/thisWill404", useSimpleHttp:true
})

[mvarvil]

Getting closer!

Okay, more testing shows that we're 2 steps closer to getting this resolved. It appears that the ListGrid fetch is causing the issues...

suspendTransaction && resendTransaction works great for these kind of requests:

isc.RPCManager.sendRequest({actionURL: "/thisWill404", useSimpleHttp:true});

arrivedFiles_DS.fetchData(dataToSend, callback, requestParams);

but it does NOT work (see previous descriptions) for this kind of request:

srchResultModule.arrivedFileResults_ListGrid.fetchData(
    dataToSend, 
    function(dsResponse, data, dsRequest) {
        afListGridFetchCallback(dsResponse, data, dsRequest); 
    }, 
    requestParams);

I also note that when the listgrid does attempts its resend, the transactionNumber is being incremented, whereas the 404 and datasource test above do not.

-- Mark

[Isomorphic]

Quick update on this: we have reproduced the issue. It's related to special error handling code in the ResultSet that allows it to deal with out-of-order replies, but which misfires in this special edge case.

However what took quite a bit of time was realizing that the code block we previously provided works only if the "Track RPCs" behavior is enabled in the Developer Console. So be sure that when testing, you turn off Track RPCs (we've already fixed the problem such that Track RPCs will not affect behavior in 7.0).

The code below works for operations that don't involve a ResultSet regardless of the setting of Track RPCs. Still working on fixing the ResultSet case.

isc.RPCManager.addClassProperties({
    handleError : function (response, request) {
        if (response.httpResponseCode==404) {
            isc.RPCManager.suspendTransaction(response.transactionNum);
            isc.Timer.setTimeout(function () {
                isc.RPCManager.resendTransaction(response.transactionNum);
            });
        }
    }
})

[Isomorphic]

The following approach works around the special additional issue of ResultSets stopping a resubmitted fetch transaction from being resubmitted more than once.

Note the code below is set up for quick testing by checking for 404 - for your final fix you want to switch to checking for 12xxx or 503.

This also won't work as is if you use DataSource.resultSetClass - let us know if that's the case and we'll devise a different approach.

isc.defineClass("MyResultSet", "ResultSet").addProperties({
    fetchRemoteDataReply : function (dsResponse, data, request) {
        if (dsResponse.httpResponseCode == 404) {
            isc.RPCManager.handleError(dsResponse, request);
        } else { 
            return this.Super("fetchRemoteDataReply", arguments);
        }
    }
})

isc.DataSource.addProperties({
    resultSetClass : "MyResultSet"
})

isc.RPCManager.addClassProperties({
    handleError : function (response, request) {
        if (response.httpResponseCode==404) {
            isc.RPCManager.suspendTransaction(response.transactionNum);
            isc.Timer.setTimeout(function () {
                isc.RPCManager.resendTransaction(response.transactionNum);
            });
        }
    }
})

[MWEA_Support]

Hello,

we recently reported several transport errors with http code 12152.

We are using SmartGWT. Can you recommend the provided solution of your last post for SmartGWT accordingly? What are the differences when implementing the method with SmartGWT instead of SmartClient or rather how should we do it in SmartGWT?

Since this post is quite old, i would also like to ask if the proposed solution of implementing the RPCManager.handleError method is still advised or if any other solutions have been found in the meantime?

The error occurs with SmartGWT version v8.2p_2013-10-12/PowerEdition, gwt 2.5.1, WinXP, IE 8 in compatibility mode.

Thanks a lot in advance!

[Isomorphic]

The corresponding API for RPCManager.handleError is RPCManager.setHandleErrorCallback, the other APIs have the same names as in SmartClient and the approach is the same.

The overall situation remains the same as well - although we've never actually seen it in person, a handful of customers see this bogus error message from IE8, and Microsoft hasn't provided a workaround.