Thank you Oleksiy,
We've applied the patch, however the problem remains.
I've uploaded two wireshark packet captures. The files can be found here:
https://app.box.com/s/zrkoqckfogg5zj7a4mjp
1) Stream_dump_rst - which contains the few HTTP requests up until IE receives the TCP RST from Glassfish
2) Stream_dump_post_rsc - which contains IE's misbehavior after attempting to resend the HTTP request after it received the TCP RST.
There are no issues reported in the log files, at least with its default logging level configuration.
I will be attempting to create a sample WAR which reproduces this problem.
-Sean
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: Wednesday, December 18, 2013 1:35 AM
To: users_at_glassfish.java.net
Subject: Re: TCP RST issues originating in Glassfish v3.1.2.2 (b5)
Hi Sean,
pls. try to apply this patch [1], it contains some grizzly related glassfish fixes, which may or may not be related to your issue.
If you still can reproduce the problem, we'll probably need more information. Can you pls. take a network traffic dump when the error occurs, is there any error reported in the log?
Ideally it would be great to have a testcase to reproduce the problem...
Thank you.
WBR,
Alexey.
[1]
https://dl.dropboxusercontent.com/u/7319744/grizzly-gf3122-patch.zip
On 17.12.13 11:36, Sean Connally wrote:
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.
================= 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.