Hi,
the timeout value might be changed in the domain.xml, like:
<protocol name="http-listener-1">
<http default-virtual-server="server" max-connections="250"
*timeout-seconds="40"*>
<file-cache></file-cache>
</http>
</protocol>
the same could be achieved with asadmin command like:
asadmin set
server-config.network-config.protocols.protocol.http-listener-1.http.timeout-seconds=40
WBR,
Alexey.
On 03/26/2012 02:32 PM, forums_at_java.net wrote:
> 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
>
>