SCRIPT7002: XMLHttpRequest: Network Error

A major travel application in North America confronted with this problem. When the users search for flights in the application, Javascript from the browser would be making calls to servers to get the content and render it. It typically takes around 8 – 10 seconds to do the complete search. During this time period Java script will make frequent polls to the server. As the itineraries becomes available on the server they will be rendered on the browser.

Fig: Showing the search bar in stuck status.

To indicate the progressiveness of the search, a ‘search bar’ displayed on the browser. Because of an unknown bug, some where in the middle of the transaction this progress bar got stuck. No results were rendered. It didn’t happen frequently but rarely it was happening. As search is a foundational element, if it didn’t work, bookings will not happen. Besides the drop in the revenue, it would also leave a bad taste with the user, who might not return back.

Developer console tools on browser didn’t give helpful error messages/hints other than blanket statement: “SCRIPT7002: XMLHttpRequest: Network Error 0x2ef3, Could not complete the operation due to error 00002ef3.”

This problem started to happen all of a sudden, out of the blue. Team started to look in to all possibilities that could trigger this problem.

1. Any server side code changes was introduced recently?

2. Any front-end (java script) code changes was introduced recently?

3. Any Load balancer settings was changed recently?

4. Any Application server setting was changed recently?

5. Any Network settings/firewall settings was changed recently?
To diagnose the problem I installed “Wireshark” and captured TCP/IP packets on the client side. When analyzing the conversation between the client machine and server, I noticed that server was prematurely issuing FIN packets in the middle of the conversation. Please see the highlighted portion of the TCP/IP conversation below:

Fig: Whireshark TCP/IP packet capture

You can see that server issue [FIN, ACK] packet when search is still in progress. When server issued FIN packet, client acknowledges (i.e. ACK) it and connection gets teared down. As there was no proper exception handling in the Javascript, when connection got teared down, Javascript aborted in the middle. Thus progress bar got stuck in the middle.

Thus this finding narrowed down that problem is triggered from the server side, whcih could be

a. Network/Firewall settings
b. Load Balancer settings
c. Application server settings.

When analyzing further, we noticed that accidently “KeepAliveTimeout” property in the Apache Load Balancer was changed to 1 second. Thus whenever application server took more than 1 second to respond, Apache load balancer’s “KeepAliveTimeout” kicked-in and started to issue ‘FIN’ packet. Thus connection was teared down.

Once “KeepAliveTimeout” property value was increased to 10 seconds, problem went away. Besides doing that exception handling on the Javascript was also strengthened. So that even if connection was reset, still Javascript will continue to make polls on the new connection.