Strange bug with JavaFX's embedded WebView browser (based on WebKit?)

[devin]

I'm trying to use an existing Smart GWT application within a Java FX application that's using a Java FX "built-in" web browser (a WebView) that I believe is based on WebKit. When I view the Smart GWT application in Chrome and Firefox it works as expected. However, in WebView in Java FX, it works, but there's an annoying artifact that occurs and I would like to see if I can get help fixing it.

The application was originally using Smart GWT 6.0. I upgraded it to Smart GWT 12.0p today to see if this is an old bug but the problem still occurs.

In a nutshell:
- there is a file browser built with Smart GWT that shows folders and files on the host
- the user can navigate into a folder by double clicking on a folder (or single slicking on a tree view on the left, the error occurs both ways)
- there is a transport error handler that shows a message "Connection lost" when there is a transport error (i.e. RPCManager.setHandleTransportErrorCallback)
- intermittently, when navigating the folder hierarchy within the Java FX app's WebView browser, the "Connection lost" error pops up and I have to double click on a folder a second time to actually go into it (it looks like the first request was just dropped/lost)

I logged the following in the transport error callback:
- transportError, transactionNum: 1415[at 1505]
- transportError, status: -90[at 1505]
- transportError, httpResponseCode: 0[at 1505]
- transportError, httpResponseText: [at 1505]

I believe that status -90 correlates to STATUS_TRANSPORT_ERROR. So I searched the forums and found the following:
https://forums.smartclient.com/forum...-response-code

Like that post, I also get this warning:
RPCManager:xmlHttpRequest.getAllResponseHeaders() returned null

However, that post was not helpful to me in debugging my problem. If I understand what Isomorphic was getting at in that post then it's an HTTP protocol layer issue. How can I check if that's the case on with my issue?

Also, I confirmed on the server side that it's not receiving an HTTP request when this occurs. I understand if there was, for example, an HTTP 500 error or something similar being sent from the server. Then I would be able to troubleshoot the cause. However, that doesn't seem to be the case. If I understand correctly, then the "httpResponseCode" is 0. This does not seem to be a valid HTTP error code (which start at 1XX I think). So my guess is the httpResponseCode is just a default variable that's set to 0 but never gets populated (no response from the server, perhaps).

I am also connected from the client to the server over a LAN, so I don't think something like network connectivity is an issue. Is it time to fire up Wireshark and dig into very low level networking stuff? If the server is not receiving an HTTP request then doesn't this indicate that the client is at fault? Also, it works fine with Chrome and Firefox, so my guess is that it has something to do with that specific Java FX WebView browser.

What could I try to help debug this further?

The full error log is as follows:
-- from our transport handler -- transportError, transactionNum: 1929[at 1505]
-- from our transport handler -- transportError, status: -90[at 1505]
-- from our transport handler -- transportError, httpResponseCode: 0[at 1505]
-- from our transport handler -- transportError, httpResponseText: [at 1505]
-- from our transport handler -- RPCManager.handleTransportError()[at 1505]
*14:45:44.407:XRP0:WARN:RPCManager:xmlHttpRequest.getAllResponseHeaders() returned null[at 1228]
*14:45:44.408:XRP0:WARN:Log:Uncaught exception escaped: Class$S5
(TypeError)
line: 2758
column: 9364
sourceURL: http://100.1.1.1/FileManager/677A517...16F.cache.html
__gwt$exception: <skipped>: null is not an object (evaluating 'c.Kq')
at CIb(http://100.1.1.1/FileManager/677A517...ache.html@9364)
at anonymous(http://100.1.1.1/FileManager/677A517....cache.html@99)
at Tb(http://100.1.1.1/FileManager/677A517....cache.html@34)
at Xb(http://100.1.1.1/FileManager/677A517....cache.html@58)
at anonymous(http://100.1.1.1/FileManager/677A517....cache.html@55)
at isc_c_RPCManager__handleError(http://100.1.1.1/Configuration/sc/mo...aBinding.js@39)
at isc_c_RPCManager_performOperationReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@17)
at isc_c_RPCManager__performTransactionReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@27)
at isc_c_RPCManager_performTransactionReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@24)
at anonymous(@-1)
at isc_c_Class_fireCallback(http://100.1.1.1/Configuration/sc/mo...ISC_Core.js@80)
at isc_c_Comm_performXmlTransactionReply(http://100.1.1.1/Configuration/sc/mo...ISC_Core.js@39)
at anonymous(@-1)
at isc_c_Class_fireCallback(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@109)
at isc_c_Comm__fireXMLCallback(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@452)
at _15(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@317)
at dispatchEvent(http://100.1.1.1/XMLHttpRequest.js@74)
at fReadyStateChange(http://100.1.1.1/XMLHttpRequest.js@25)
at onreadystatechange(http://100.1.1.1/XMLHttpRequest.js@23)[at 1228]

[devin]

So I got a Wireshark capture (attached) and it does indeed look like "TCP socket issues". I don't fully understand this capture yet, but it looks like:
- the client successfully sent an HTTP POST request to the server
- the client then sent a [FIN, ACK] to the server
- the server didn't receive the HTTP POST request
- the server instead sent a [RST] response (closed the socket due to [FIN,ACK] ???)

I'll try to dig further, but it looks like Isomorphic is correct in that other thread (and perhaps I should have asked my question there instead of creating a new thread, thinking my problem was different).

[devin]

As a side question, in the following documentation:
https://www.smartclient.com/smartgwt...ErrorCallback-

it states:
"This provides the developer with an opportunity to handle a server error by (for example) suspending and resubmitting the transaction before any other handling occurs."

Would it be possible for me to catch when this transport error occurs in the transport error handler and to resend the request? I know this is more of a band-aid solution rather than fixing the underlying problem.

However, if this is possible, then how could I do that from the transport error handler? Since it doesn't seem to have access to the original request. Can I get the original request that failed using the transaction number parameter that's passed to the callback?

[devin]

I'm guessing RPCManager.resendTransaction should do this. I just tried the following but the POST request was not re-sent (verified in Wireshark):

if (RPCResponse.STATUS_TRANSPORT_ERROR == status && 0 == httpResponseCode) {
              RPCManager.resendTransaction(transactionNum);
}

-- transport error handler code -- resending failed transaction # 22 that failed with status: -90[at 1500]
*08:41:47.554:XRP8:WARN:RPCManager:xmlHttpRequest.getAllResponseHeaders() returned null[at 1228]
*08:41:47.557:XRP8:WARN:Log:Uncaught exception escaped: Class$S5
(TypeError)
line: 2757
column: 9513
sourceURL: http://100.1.1.1/FileManager/FF6C88E...893.cache.html
__gwt$exception: <skipped>: null is not an object (evaluating 'c.Kq')
at CIb(http://100.1.1.1/FileManager/FF6C88E...ache.html@9513)
at anonymous(http://100.1.1.1/FileManager/FF6C88E....cache.html@99)
at Tb(http://100.1.1.1/FileManager/FF6C88E....cache.html@34)
at Xb(http://100.1.1.1/FileManager/FF6C88E....cache.html@58)
at anonymous(http://100.1.1.1/FileManager/FF6C88E....cache.html@55)
at isc_c_RPCManager__handleError(http://100.1.1.1/Configuration/sc/mo...aBinding.js@39)
at isc_c_RPCManager_performOperationReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@17)
at isc_c_RPCManager__performTransactionReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@27)
at isc_c_RPCManager_performTransactionReply(http://100.1.1.1/Configuration/sc/mo...aBinding.js@24)
at anonymous(@-1)
at isc_c_Class_fireCallback(http://100.1.1.1/Configuration/sc/mo...ISC_Core.js@80)
at isc_c_Comm_performXmlTransactionReply(http://100.1.1.1/Configuration/sc/mo...ISC_Core.js@39)
at anonymous(@-1)
at isc_c_Class_fireCallback(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@109)
at isc_c_Comm__fireXMLCallback(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@452)
at _15(http://100.1.1.1/Configuration/sc/mo...SC_Core.js@317)
at dispatchEvent(http://100.1.1.1/XMLHttpRequest.js@74)
at fReadyStateChange(http://100.1.1.1/XMLHttpRequest.js@25)
at onreadystatechange(http://100.1.1.1/XMLHttpRequest.js@23)[at 1228]

[devin]

So I figured this out. The HTTP server that we're using (an old embedded C based server) was closing a socket for an HTTP keep-alive session without informing the HTTP client first.

i.e.
client -> server HTTP request with "Connection: keep-alive"
server -> client HTTP response with "Connection: keep-alive" (should be "Connection: close" in the header instead)
server then closes the TCP/IP socket
client -> server HTTP request. trying to use the same socket, which gets lots because the server already closed that socket (this somehow results in the client sending [FIN,ACK], perhaps as a way to tell the server that it only now realizes that the socket is closed) and the server follows up with [RST] (I guess to tell the client, yeah, sorry, I closed this socket already)