Hi Jim,
30 seconds sounds like an idle connection timeout we use on Glassfish by
default.
We apply this timeout value on HTTP keep-alive connections, when they
are in idle state. So if we try to keep HTTP keep-alive connection is
the idle state longer than 30 seconds - GF closes it.
Looks like WL plugin caches HTTP response and doesn't send it back until
connection is not closed. Probably WL plugin expects more HTTP payload
to be sent from GF, but AFAIK 304 response can not have any payload.
WBR,
Alexey.
On 03/24/2012 01:18 AM, forums_at_java.net wrote:
> Alexey,
>
> Thanks. However, as I said in my post, when we switched just that one
> <Location> section in the Apache httpd.conf from using the WL plugin
> to using
> ProxyPass/ProxyPassReverse, we no longer saw the 30.0x pause for
> getting the
> .js files under those URIs, even without having to use the ttl on the
> ProxyPass directive.
>
> I am always uncomfortable when something works when I don't understand
> WHY it
> works, so what I'm really trying to figure out is: What was it about the
> communication between the Apache and the GF 3.1.1, when using the WL
> Plugin
> for Apache, that caused those 30.0x second pauses?
>
> I've checked the WL Plugin debug logging, and what I see in those logs
> is:
>
> - Apache gets the request
>
> - WL Plugin passes the request through to GF
>
> - GF appears to send the response back to WL Plugin
>
> - WL Plugin sends some response headers back to client (the browser,
> FF 3.6
> in this case)
>
> - Then, there's a 30 second gap in the WL Plugin log
>
> - Then, we see a msg in the WL Plugin log that says "canRecycle
> status=304
> clen=-1"
>
> That last WL Plugin log line is, I think, saying that the WL Plugin was
> closing the connection to GF, but there's not info about why it took
> 30 secs
> to get to that point, i.e., no errors, and nothing about the WL Plugin
> timing
> out.
>
> I've spent much time trying to diagnose this, but with no success. At
> this
> point, I guess that we just have to live with having to use mod_proxy for
> proxying the .js static files, and not understanding why :(...
>
>
>
> Thanks again,
>
> Jim
>
>
>
> [quote=oleksiys]Hi Jim, if you use mod_proxy, try to specify ttl param
> like:
> ProxyPass / ajp://127.0.0.1:8009/ ttl=60 or try mod_jk, which supposed
> to be
> more stable. WBR, Alexey. On 03/23/2012 02:29 AM, forums_at_java.net
> wrote: >
> Hi, > > I posted the above several months ago, and never got any
> responses,
> but > wanted to provide some additional info in case it might help
> anyone in
> > the > future. > > We've been using the WebLogic Plugin for Apache for
> proxying to GF > 3.1.1 for > awhile, and it's generally been working
> fine,
> until recently, we > encountered > a problem when we had the GF
> serving some
> static .js files. The problem > that we ran into was even though some of
> those .js files were a > variety of > sizes, including some that were
> quite
> small, on some of them (specific > .js > files), we were seeing
> consistent
> load times of 30.0x seconds, whereas > other > .js file file would
> load in
> millisecs. > > We were kind of thrashing around, and we finally tried
> switching the > section in the Apache that was proxying one of the URI >
> roots to > use mod_proxy instead of the WebLogic Plugin. Then, when we
> tested
> after > bouncing the Apache sefver, no more 30.0x second load times for
> anything. > Everything was fast. > > I've tried switching to mod_proxy on
> another test system where I had been > able to simulate the 30 second
> load
> time earlier, but on this second > system, > switching to mod_proxy
> caused a
> 50x error instead. > > So, I'm kind of coming to the conclusion that
> there is
> something > "strange" > with GF 3.1.1 on Windows 64-bit, in the area of
> communications > (HTTP/HTTPS) > handling. I don't know what that is, but
> thought that I'd post this info > here, in case it helps anyone else. > >
> Later, > > Jim > > > -- > > [Message sent by forum member 'jimcpl'] >
> > View
> Post: http://forums.java.net/node/882878 > >[/quote]
>
>
> --
>
> [Message sent by forum member 'jimcpl']
>
> View Post: http://forums.java.net/node/882878
>
>