Hi Sean,
it's very possible that Glassfish doesn't send RST in response to
client's request. This request comes 30 seconds after the last request
has been processed, so it's very possible that idle connection timeout
is triggered and it's just a matter of "luck" that is happens approx at
the same time when the 2nd request is sent.
Let's increase the idle connection timeout to see if these 2 facts are
related or not.
$asadmin set
server-config.network-config.protocols.protocol.http-listener-1.http.timeout-seconds=60
In the command above we changed timeout for http-listener-1, if you use
another listener - pls. change the command.
Thanks.
WBR,
Alexey.
On 20.12.13 08:33, Sean Connally wrote:
>
> 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.
>