Logs show reasonable request handling duration, but proxied clients timing out

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA8E25.9917A0F2
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For sometime I've had complaints from one of the users of a particular
mod_perl handler that is timing out on their end. They are using a
programmatic Java client, accessing a mod_perl registry handler that
simply returns a text file.

The client is accessing my servers via a proxy which then connects to a
load balancer that balances between two of my boxes.

The client uses a 500 millisecond read timeout which is often reached,
causing the client process to throw exceptions. However, when I look at
my logs, the %D param shows durations well below this limit.

At times I do not see the requests at all.

What should I be looking at on my servers to see if the problem is on my
end?

As much as it appears that the problem is in the proxies, I want to make
sure that I've covered all the bases from my end before I escalate the
issue.

There are no fixup handlers or log handlers, which I believe might
impact post-logging timings.

Thanks, everybody.

Eric

_______________________________________________

This e-mail may contain information that is confidential, privileged or o=
therwise protected from disclosure. If you are not an intended recipient =
of this e-mail, do not duplicate or redistribute it by any means. Please =
delete it and any attachments and notify the sender that you have receive=
d it in error. Unless specifically indicated, this e-mail is not an offer=
to buy or sell or a solicitation to buy or sell any securities, invest=
ment products or other financial product or service, an official confirma=
tion of any transaction, or an official statement of Barclays. Any views =
or opinions presented are solely those of the author and do not necessari=
ly represent those of Barclays. This e-mail is subject to terms available=
at the following link: www.barcap.com/emaildisclaimer. By messaging wi=
th Barclays you consent to the foregoing. Barclays Capital is the invest=
ment banking division of Barclays Bank PLC, a company registered in Engla=
nd (number 1026167) with its registered office at 1 Churchill Place, Lond=
on, E14 5HP. This email may relate to or be sent from other members of t=
he Barclays Group.
_______________________________________________

------_=_NextPart_001_01CA8E25.9917A0F2
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:=
schemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html=
40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

For sometime I’ve had complaints from one of the=
users
of a particular mod_perl handler that is timing out on their end. T=
hey
are using a programmatic Java client, accessing a mod_perl registry handl=
er
that simply returns a text file.<o:p></o:p>

<o:p> </o:p>

The client is accessing my servers via a proxy which t=
hen
connects to a load balancer that balances between two of my boxes.<o:p></=
o:p>

<o:p> </o:p>

The client uses a 500 millisecond read timeout which i=
s
often reached, causing the client process to throw exceptions. Howe=
ver,
when I look at my logs, the %D param shows durations well below this limi=
t.<o:p></o:p>

<o:p> </o:p>

At times I do not see the requests at all.<o:p></o:p><=
/span>

<o:p> </o:p>

What should I be looking at on my servers to see if th=
e
problem is on my end?<o:p></o:p>

<o:p> </o:p>

As much as it appears that the problem is in the proxi=
es, I
want to make sure that I’ve covered all the bases from my end befor=
e I escalate
the issue.<o:p></o:p>

<o:p> </o:p>

There are no fixup handlers or log handlers, which I b=
elieve
might impact post-logging timings.<o:p></o:p>

<o:p> </o:p>

Thanks, everybody.<o:p></o:p>

<o:p> </o:p>

Eric<o:p></o:p>

</div>


_______________________________________________<=
?xml:namespace
prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office"
/><o:p></o:p>
<o:p> </o:p>
This e-mail may =
contain
information that is confidential, privileged or otherwise protected from =

disclosure. If you are not an intended recipient of this e-mail, do not
duplicate or redistribute it by any means. Please delete it and any attac=
hments
and notify the sender that you have received it in error. Unless specific=
ally
indicated, this e-mail is not an offer to buy or sell or a solicitation t=
o buy
or sell any securities, investment products or other financial product or=

service, an official confirmation of any transaction, or an official stat=
ement
of Barclays. Any views or opinions presented are solely those of the auth=
or and
do not necessarily represent those of Barclays. This e-mail is subject to=
terms
available at the following link: <A
href=3D"http://www.barcap.com/emaildisclaimer">www.barcap.co m/emaildiscla=
imer</A>.
By =
messaging
with Barclays you consent to the foregoing. Barclays Capital is the investm=
ent
banking division of Barclays Bank PLC, a company registered in <?xml:name=
space
prefix =3D st1 ns =3D "urn:schemas-microsoft-com:office:smarttags" /><st1=
:place
w:st=3D"on"><st1:country-region w:st=3D"on">England</st1:country-region><=
/st1:place>
(number 1026167) with its registered office at <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">1 Churchill Place</st1:Street>, <st1:=
City
w:st=3D"on">London</st1:City>, <st1:PostalCode w:st=3D"on">E14
5HP</st1:PostalCode></st1:address>.&nbs=
p;
This email may relate to or be sent from other members of the Barc=
lays
Group.<o:p></o:p></SP=
AN>
_______________________________________________<=
/FONT>
</body>

</html>

------_=_NextPart_001_01CA8E25.9917A0F2--

Logs show reasonable request handling duration, but proxied clients timing out

Re: Logs show reasonable request handling duration, but proxied