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.
>