users@glassfish.java.net

TCP RST issues originating in Glassfish v3.1.2.2 (b5)

From: Sean Connally <ConnallyS_at_wrapsnet.org>
Date: Tue, 17 Dec 2013 19:36:18 +0000

Hello,
I am hoping someone can assist me with a problem I am experience, in what I think is originating from Glassfish 3.1.2.2, or maybe a bad combination of a behavior in GF and Internet Explorer 9.

I have deployed a Java EE app, which runs a JavaScript timer on the web-browser to poll the server (servlet in glassfish) via an ajax call to simply check for server availability. Throughout the day, this poll will fail in a very unusual way: the HTTP body will be empty when it shouldn't be. The poll operation makes this problem most visible, but often other, less visible, async operations will fail too.

We've done a pretty thorough investigation and discovered that IE probably has a defect which is causing this problem, but at the same time I can't imagine GF behaving in this way to make IE exhibit it's defect. From my examinations, everything works fine until IE attempts to make an HTTP request on a keep-alive connection and receives a TCP RST instead. IE will then re-establish the TCP/HTTP connection, but will only send the HTTP headers. GF waits 300 seconds to receive the HTTP Body, never does; finally GF then sends what it has for the HTTP request through the server stack to the servlet.

I've attempted to disable HTTP keep-alive by setting the Max HTTP keep-alive connections to 1. This appears to have helped, but it does not eliminate the problem. Plus I would prefer to not disable keep-alive.

Given the prevalence of Internet Explorer, I can't imagine GF is exhibiting this problem for other company's else I'd have seen more reports of it on the internet. I am suspecting it's a configuration issue, but I can't pinpoint what I need to change. We've tried various configuration tweaks with no luck. Any ideas?

Thanks
-Sean



================= Disclaimer: The content of this email message and any attachments are intended for specific recipients and are privileged and confidential. If you have received this email in error, please kindly delete its contents and advise the Refugee Processing Center (RPC) via reply e-mail of the delivery mistake.