Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: "Ryan Murray" <ryan.murray@elementn.com>
To: <users@httpd.apache.org>
Date: Wed, 10 Jun 2009 10:08:49 +0300
Organization: elementn^n
Message-ID: <006401c9e99a$4f988200$6b00000a@TIGER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcnpS17bbnf7XTDoRzKYvWUn1mJb4gATnpwA
In-Reply-To: <ffb3a35a0906091443x59160cc7i3026bd5f4b3f8b6c@mail.gmail.com>
Subject: RE: [users@httpd] 503 status seems to get cached - how do I disable
 caching?

Did you check the timeout on your apache proxy config?  Once apache has =
detected the backend is not available it won't retry again until a =
certain number of seconds (timeout) has passed.  I pretty sure mod_proxy =
defaults to 60 seconds, which I usually reduce to get a quicker recovery =
when Tomcat is back up. =20

Ryan Murray
elementn^n

-----Original Message-----
From: Jenny Brown [mailto:skywind@gmail.com]=20
Sent: Wednesday, June 10, 2009 12:43 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] 503 status seems to get cached - how do I =
disable caching?

Ok, I tried testing for the hung ajp sockets concept, and got some
other useful info too.  Problem still remains.

Procedure:
I stopped all services that make requests to this dev web server (so I
am the only user on).
I stopped both tomcat and apache, and make sure all processes had
exited. (Goal- eliminate open sockets.)
I started apache and then tomcat.
I logged in to tomcat's manager app via both urls (one through apache,
one direct on port 8080), and authenticated.  Page came up.

I shut down tomcat, refreshed both browser windows, confirmed accurate
service-not-available message.  This is also the step that would get
the error message into apache httpd's cache.

Results:
I started tomcat, waited several seconds, and refreshed both browser
windows.  Tomcat-8080 came up fine.  Apache still showed the error
message.

I bounced on shift-control-r (refresh without browser cache) about
once per second, in the apache window, for a while.  About 40 seconds
later (by the clock) apache finally figured out that tomcat was back
up.


Issue:
Is it possible that apache is caching because the same request is
coming over and over within a small time frame?   Or that there's a
header it's setting in the response that affects results?  I'm still
puzzled.   Thanks.


Jenny Brown


On Tue, Jun 9, 2009 at 3:37 PM, Jenny Brown<skywind@gmail.com> wrote:
> Regarding the possibility of hung AJP sockets:
>
> That's an interesting question.  I have a dev environment where I
> could test it out, though it'll be a while before I get an opportunity
> to do so.  If I can confirm that the absence of pending requests makes
> the response time faster, I'll let you know.  Likewise if that's not
> the issue, I'm back to the drawing board on it.
>
> Thanks for the ideas.
>
> Jenny Brown
>
>
> On Mon, Jun 8, 2009 at 1:13 PM, Andr=C3=A9 Warnier<aw@ice-sa.com> =
wrote:
>> Jenny Brown wrote:
>>>
>>> On Mon, Jun 8, 2009 at 12:50 PM, Jenny Brown<skywind@gmail.com> =
wrote:
>>>>>
>>>>> What you should really try, is to use the browser to access that =
same
>>>>> URL
>>>>> directly on Tomcat, without going through Apache, and see how long =
you
>>>>> have
>>>>> to wait there to get an answer after you start Tomcat.
>>>>
>>>> Hitting tomcat directly on port 8080 is very fast.  That difference =
in
>>>> speed is what led me to believe that apache seemed to be caching.
>>>
>>> To clarify this a bit:
>>>
>>> In a single web browser, I can load
>>> http://www.myserver.com:8080/manager/html/ in tomcat and see =
results,
>>> and load http://www.myserver.com/manager/html/ in another window
>>> (routes through apache, then ajp to tomcat) and see 503 -- at the =
same
>>> time.
>>>
>>> That is, tomcat is up, the manager web app is answering requests, =
and
>>> I can interact with it normally, for a significant amount of time,
>>> while apache continues to say it can't get to it.
>>>
>>>
>> Allright, so you have done your testing properly.  I just wanted to =
make
>> sure you were looking at the right issue (I've had webapps that took =
10
>> minutes to get ready to process requests).
>>
>> And you are using mod_proxy_ajp as a connector, with which I am not
>> familiar, so I'll just dream up a scenario for the issue, and maybe a
>> specialist can tell us if I'm wrong.
>>
>> Let's imagine that there is a limited pool of mod_proxy_ajp threads =
or
>> processes that can potentially forward requests to Tomcat.  Say there =
are 15
>> of them, no more.
>> Now 15 requests are issued to Apache at the same time, which should =
get
>> proxied to Tomcat.  Each request is processed by one of the =
mod_proxy_ajp
>> threads, they all set up a connection to Tomcat, and send their =
request.
>> Next, Tomcat goes down.  The ajp threads are still waiting for a =
response.
>>  They will keep waiting until some timeout occurs.
>> Now more requests arrive in httpd, really for Tomcat.
>> But because the 15 ajp threads are busy waiting, these requests have =
to wait
>> (for a free ajp thread).
>> Now Tomcat comes back up, but of course that does not help the apache =
ajp
>> threads, who are still waiting on the wrong sockets.
>> A direct request to Tomcat goes through quickly.
>> A request through Apache however, has to wait for one of the stuck =
ajp
>> threads to realise that there is a problem, and build a new =
connection to
>> Tomcat.
>> AJP specialists, what's wrong with the above ?
>>
>> To Jenny : if you were using mod_jk instead of mod_proxy_ajp, then I =
think
>> something like the cping/cpong feature may help you shorten the =
response
>> time.  But I don't know if mod_proxy_ajp has something similar.
>>
>> I would also in the meantime check if you have the latest version of
>> mod_proxy_ajp.  It is a (relatively) recent module, in which a lot of
>> changes have happened over the last few months.  Maybe what you are =
seeing
>> is related to something since corrected.
>>
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server =
Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server =
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org