Hi,
What you said is also one of the things that I suspect might be happening.
Can you tell me where that timeout is configured in GF? If I knew that, I
could do an experiment where I change from 30 secs to, say, 40 secs, and see
if the gap increases to 40 secs.
Having said that, as I said, I've been checking the WL Plugin logs, which we
have set for "Debug ALL", and 30 secs after the plugin sends headers to the
client (the Firefox), I see the "canRecycle" log message. I was hoping that
the "clen" (presumably the content-length) would show some positive number,
but as mentioned earlier, it's showing "-1", whatever that it.
Jim
[quote=oleksiys]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 > 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 >
>[/quote]
--
[Message sent by forum member 'jimcpl']
View Post: http://forums.java.net/node/882878