I am having an issue with the latest Pound 1.9.  We use Business Objects and
we put Pound in front of the server.

The problem is when the client, using IE6, tries to download an Excel file,
the user only has X amount of seconds to pick a location to save the file,
where X is the Client timeout value in Pound, before Pound responds with a
"error copy server cont: Connection timed out", and the client only gets a
partial file.  We have other issues with Business Objects refreshing pages
which server PDF content when Client timeout is set high, so we can either
give the user a long time to save the file, which delays all PDF pages from
viewing; or reduce PDF page load time, but increase the possibility the file
doesn't download in time.

This problem affects all downloads, but specifically those downloads where
the Excel file size is 300K or larger, where only 115k or so of the file
actually gets downloaded before the server connection is reset.

I have fronted another server with the same Pound server, and a similar
download operation works, but the server which is working has
Transfer-Encoding set to chunked, whereas the server which has the problem
is sending a Content-Length header.

I have tried older version of Pound, no help, and I have tried other
versions of IE, no help.  If I use FireFox, I have no problem, so the
problem seems IE specific.

There seems to be some interaction between IE6 and Pound and the backend
server.

I've attached my configuration as well as header requests and responses
which work and don't work.  If there are any setting changes, or suggestions
you have to solve this mystery, I would greatly appreciate it.

Thanks for your help,
Steven


Pound Configuration:

ListenHTTP 10.2.1.165,80

User    root
Group   root
LogLevel 0

#Client 20

UrlGroup "/wiasp.*"
BackEnd ConsbowiProd3,80,1
BackEnd ConsbowiProd4,80,1
Session IP 1800
EndGroup


Headers which work:

GET /agreement/ViewAttachmentPage.aspx?pkAgreementAttachment=4293 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://www.XXX.com/agreement/AgreementSummary.aspx?pkAgreement=5203&pkAgreem
entVersion=2346
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: www.XXX.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDSADSDQSB=BBIGLJHCFNNCGGAGOPMCJAED;
ASP.NET_SessionId=joigymvcyyrran45rbrn3kus; testcookie=test;
Opus3Login=37A91A9FD2371FE4EA09386A629AA9E5C238DF0CA794AA4890E86A762CE6D86E1
57E22B9ACC9EAE686D49F3F73BB1CA94341AC8D1CB151B99FA634EAFF41D2740824B105796FB
F35; RaptorID=u=svlach; RaptorAuthIDV2=664496847


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 13 Jun 2005 18:24:55 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Content-Disposition: attachment; filename=ad11343.20040401.xls
Transfer-Encoding: chunked
Cache-Control: private
Content-Type: application/vnd.ms-excel



Headers which don't work:

GET
/wiasp/scripts/saveAsXLS.asp?cmdP1=%5F%2A16526%2A0%2Arep%2Awi00000004&sEntry
=wi00000004&viewType=&download=&oawReportName= HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/scripts/downloadWait.asp?ctxLayout_last=doc
umentXML.asp&cmdLayout=&cmdLayout_P1=&cmdLayout_P2=&cmdBlock=all&cmd=askSave
&cmdP1=Agreement+Index+by+Contract+Area*16526*0*rep*wi00000004&cmdP2=&sEntry
=&download=&viewType=&dwnldpage=saveAsXLS.asp&oawReportName=
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: www.XXX.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDSSBTAQDA=OKKJIIDAHDHHCKMOJLPMBGIO;
WebIntelligenceSession=601%5F1734080301%24en38D0298C4510190A1A770B54QT0


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 13 Jun 2005 20:11:56 GMT
Content-disposition: attachment;
filename="Agreement_Index_by_Contract_Area.xls"
Content-Length: 315058
Content-Type: application/vnd.ms-excel
Expires: Mon, 13 Jun 2005 20:13:56 GMT
Cache-control: private

Hi,

I am trying again to see if anyone has any suggestions on this problem.

Thanks,
Steven


-----Original Message-----
From: Steven Vlach [mailto:Home_Boy(at)msn.com] 
Sent: Monday, June 13, 2005 4:11 PM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] Issue with Pound, Client Timeouts, IE and
saving attachments

I am having an issue with the latest Pound 1.9.  We use Business Objects and
we put Pound in front of the server.

The problem is when the client, using IE6, tries to download an Excel file,
the user only has X amount of seconds to pick a location to save the file,
where X is the Client timeout value in Pound, before Pound responds with a
"error copy server cont: Connection timed out", and the client only gets a
partial file.  We have other issues with Business Objects refreshing pages
which server PDF content when Client timeout is set high, so we can either
give the user a long time to save the file, which delays all PDF pages from
viewing; or reduce PDF page load time, but increase the possibility the file
doesn't download in time.

This problem affects all downloads, but specifically those downloads where
the Excel file size is 300K or larger, where only 115k or so of the file
actually gets downloaded before the server connection is reset.

I have fronted another server with the same Pound server, and a similar
download operation works, but the server which is working has
Transfer-Encoding set to chunked, whereas the server which has the problem
is sending a Content-Length header.

I have tried older version of Pound, no help, and I have tried other
versions of IE, no help.  If I use FireFox, I have no problem, so the
problem seems IE specific.

There seems to be some interaction between IE6 and Pound and the backend
server.

I've attached my configuration as well as header requests and responses
which work and don't work.  If there are any setting changes, or suggestions
you have to solve this mystery, I would greatly appreciate it.

Thanks for your help,
Steven


Pound Configuration:

ListenHTTP 10.2.1.165,80

User    root
Group   root
LogLevel 0

#Client 20

UrlGroup "/wiasp.*"
BackEnd ConsbowiProd3,80,1
BackEnd ConsbowiProd4,80,1
Session IP 1800
EndGroup


Headers which work:

GET /agreement/ViewAttachmentPage.aspx?pkAgreementAttachment=4293 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://www.XXX.com/agreement/AgreementSummary.aspx?pkAgreement=5203&pkAgreem
entVersion=2346
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: www.XXX.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDSADSDQSB=BBIGLJHCFNNCGGAGOPMCJAED;
ASP.NET_SessionId=joigymvcyyrran45rbrn3kus; testcookie=test;
Opus3Login=37A91A9FD2371FE4EA09386A629AA9E5C238DF0CA794AA4890E86A762CE6D86E1
57E22B9ACC9EAE686D49F3F73BB1CA94341AC8D1CB151B99FA634EAFF41D2740824B105796FB
F35; RaptorID=u=svlach; RaptorAuthIDV2=664496847


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 13 Jun 2005 18:24:55 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Content-Disposition: attachment; filename=ad11343.20040401.xls
Transfer-Encoding: chunked
Cache-Control: private
Content-Type: application/vnd.ms-excel



Headers which don't work:

GET
/wiasp/scripts/saveAsXLS.asp?cmdP1=%5F%2A16526%2A0%2Arep%2Awi00000004&sEntry
=wi00000004&viewType=&download=&oawReportName= HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/scripts/downloadWait.asp?ctxLayout_last=doc
umentXML.asp&cmdLayout=&cmdLayout_P1=&cmdLayout_P2=&cmdBlock=all&cmd=askSave
&cmdP1=Agreement+Index+by+Contract+Area*16526*0*rep*wi00000004&cmdP2=&sEntry
=&download=&viewType=&dwnldpage=saveAsXLS.asp&oawReportName=
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: www.XXX.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDSSBTAQDA=OKKJIIDAHDHHCKMOJLPMBGIO;
WebIntelligenceSession=601%5F1734080301%24en38D0298C4510190A1A770B54QT0


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 13 Jun 2005 20:11:56 GMT
Content-disposition: attachment;
filename="Agreement_Index_by_Contract_Area.xls"
Content-Length: 315058
Content-Type: application/vnd.ms-excel
Expires: Mon, 13 Jun 2005 20:13:56 GMT
Cache-control: private
[...]

On Thu, 23 Jun 2005 16:45:37 -0500 "Steven Vlach" <Home_Boy(at)msn.com>
wrote:
[...]
problem.[...]
and[...]
Objects and[...]
file,[...]
file,[...]
with a[...]
gets a[...]
pages[...]
either[...]
from[...]
the file[...]

I find this really confusing: how does the Client value affect
downloads? All it does is to say "if the client is inactive more than n
seconds drop the connection". During a download there should be no
time-out at all.
[...]
where[...]
file[...]

Again this is a separate issue. Some browsers start the download while
showing the pop-up dialog, so some data is received even before the user
clicked on it.
[...]
similar[...]
problem[...]

That I believe right away.
[...]
backend[...]
responses[...]
suggestions[...]
HTTP/1.1[...]
Tablet[...]
D86E1[...]
796FB[...]
Entry[...]
kSave[...]
Entry[...]
Tablet[...]
pound(at)apsis.ch.[...]

What I notice is that you have some sort of cache involved (notice the
cache control headers) and that in the example that doesn't work the
cache expiry is set to two minutes. Could this be the issue here?[...]

Hi Robert,

Thanks for the reply.  Please see my comments below.
[...]

That is exactly what is happening, and makes no sense to me either.  How
does Pound know that a transfer is in place and not to timeout the client??
Perhaps the server isn't setting something for Pound to know it's a transfer
and not to timeout the client??
[...]

I agree, the partial file isn't so much the problem, timing out is the
issue.
[...]

I know, it's hard to believe that IE would have a problem.  ;-)
[...]

I've removed the cache setting all together, and then results are the same.
Actually the application sets it to -1, but I changed it to 2 minutes for
testing, and now removed the setting entirely, but no help.

Thanks for looking into this issue, I'm sure that we'll be able to figure it
out.

Steven
[...]

After further testing, it seems that if the attachment is too large for the
browser to deal with in one swipe, then the timeout will occur in Pound. If
the file is small enough for the browser to deal with, then no problem.  It
seems that Pound is not waiting for the user to choose to save the file, or
pick the location for the saved file, but simply waiting its timeout value
and then quitting.

Is there a patch available for Pound to allow it to wait for a user response
if the header is an Attachment?

Thanks,
Steven


[...]

On Mon, 27 Jun 2005 11:18:16 -0500 "Steven Vlach" <Home_Boy(at)msn.com>
wrote:
[...]
for the[...]
Pound. If[...]
problem.  It[...]
file, or[...]
value[...]
response[...]

I would suggest you try to understand how the transfer works before you
sit and write some patches. There is no user response at all - the whole
thing happens in the browser: it detects that the response is a file (or
something of that nature) and asks the user what to do with it. Most
modern browsers also start to receive at least part of this file while
waiting for the user response. There also is no such thing as an
"attachment" in the HTTP protocol.

From Pound's point of view it sends a response to the browser. The
fact that this transfer is slow is just a side-effect - you won't see
anything else.

It may very well happen that the back-end server times-out here, but
that's another matter.[...]

Robert, I can pretty much guarantee that the issue he's seeing is *not* 
due to a backend server timing out.

My own theory is that it's something to do with one of two things:

1. pound detecting that the server side of a connection has closed, and 
then flushing its buffer/destroying the buffer before the last of the 
input is read from the inbound data stream, then saying "welp, I've got 
no more data to send to the client, so I might as well close the client 
side, too."

2. pound detecting that the server side of a connection has closed, and 
closing the client side of a connection before sending any remaining 
data to the client that may be buffered inside of pound.

[In either case, pound's prematurely severing the client side connection 
when the server side connection is severed prematurely.]

Now, you would know better than I the inner workings of pound, but I'm 
pretty good at "black-box" engineering.  I know the HTTP protocol, I 
know what's going into pound, I can see what's coming out, and I have a 
good feeling it's related to one of the above.

I had a similar problem, in a situation consisting of:

1. Backend server with gigabit NICs.
2. Pound, with gigabit NICs.
3. Clients with 10 or 100 megabit NICs.  (Or even slower, if they were 
remote/dialup users.)
4. Web server not sending content-length header.
5. large files, such as executables, images, PDFs, being cut off in 
mid-stream by the pound.

(and, I *know* it was pound, because when running other load-balancing 
apps -- balance, and plb, the issue plain old did *not* happen.  [Yes,
I've considered switching, but pound has the features I need.  plb 
patched to pass an X-forwarded-for header comes close, though.])  When I 
run it through pound, it did.  Hell, when I ran it first thru plb or 
balance and *then* through pound, it happened.

Pound was *the* **only** ***constant***.  When you plugged pound into 
the equation, things started to break.

As the Sherlock Holmes tales go, when you exhaust every possibility, 
whatever is left, no matter how improbable, is the truth.  Pound's 
broken, somewhere.

I figure that the pound-server transaction was taking place VERY quickly [...]

I'll try to show you an example of what happens. If you consider this
broken please suggest a fix:

Assume you have a back-end server (reasonably fast) and a rather slow
client. The client sends a request and the server starts sending the
reply. As the client is slow (perhaps a slow network connection, or
perhaps some user interaction as in the OP example) the server decides
at some point that the client timed-out and closes the connection. Net
result: the client received some data, but not all.

So far I think you would agree that this is normal behavior, pretty
much as you would expect things to happen. Now let's add Pound into the
mix.

By itself Pound does no real buffering (it would be more correct to say
it does minimal buffering, but we can ignore it for the sake of this
discussion). What Pound does is to watch carefully both the server and
the client connections for inactivity and abort the connection if either
of them times-out. The config parameters are Client and Server.

As in the above example there is a request and the response starts
coming back. Pound reads a bit of it and sends it to the client, but if
the client is very slow (e.g. dial-up) it may well happen that the
write() will time-out! The result is that the connection is closed after
sending some data. The only "cure" is to increase the Client value, as
it will allow the write() to complete in time.

Finally, the other programs you mention: as far as I know they do not
implement connection time-out, and thus do not suffer from this problem.[...]

Hi All,

I can see how the scenario below works, and agree with how the timeouts
operate in Pound and the reasoning behind them.

There are actually 2 "problems" we are experiencing, and if one gets fixed,
then the other issue is moot.  The problem you describe below is the one
issue we are having with a low client timeout issue affecting the ability of
the user to respond to an "attachment" disposition ie. saving a file quick
enough for Pound.  Fair enough, I can increase the timeout value and give
the user enough time to choose a file location etc.

The other issue we are having is that another part of our web application
(Business Objects) serves up PDF files to be displayed in the browser, and
somehow the pdf does not display in the IE browser *until the client timeout
value is reached.  I am not sure, but I believe this issue has something to
do with IE opening up exactly 4 connections, and Pound needing to "expire"
those connections in order for the last html to arrive at the browser.  In
this application (maybe all), IE doesn't display the pdf until all of the
html for the page is delivered, which causes the delay, maybe due to
buffering or something.  The application serves up the pdf quickly, but
additional labels on the screen don't arrive until after the client timeout
value occurs, which delays the pdf from displaying. The web server serves up
http 1.1 responses for everything except the pdf generation, then it
generates http 1.0 responses (which is generated by a server-side dll).
This change in protocols may be confusing the browser, I'm not sure.

So, you see, if I raise the client timeout issue to say, 30 seconds, then
each pdf generation is delayed for 30 seconds, but the user has 30 seconds
to respond to the save attachment dialog.  If I decrease the client timeout
to 1 (which I read is required for certain IE applications with Pound), then
pdfs generate quickly, but the user has only 1 second to choose a save
location, not practical.

I'm including the headers for the pdf generation to see if you can shed
light on this issue. I apologize for the size of the headers and
information.  There is a 10 second delay between packet #4 and packet #5,
which coincides with a client timeout value of 10.  If I make the client
timeout = 30, then the delay between packet 4 and 5 becomes 30 seconds.

I want to thank you and the others who have taken interest in this issue.
We have used Pound for over 2 years now, and really appreciate the quality
of the code, the flexibility of the configurations, and the features which
are included which aren't available in other products.

Steven


Request/Response #1

GET /wiasp/images/skin_default/doc_anim.gif HTTP/1.1
Accept: */*
Referer:
http://cosmos.consorta.com/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/Get
Document?sEntry=wi00000001&sForceRefresh=Y&sOpen=&sHTMLPath=/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 25 Apr 2005 19:17:56 GMT
If-None-Match: "a8412d7ccb49c51:1610"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: cosmos.consorta.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDQQDRAQDA=KOLJIIDAKGCFNODBGJIPILLP;
WebIntelligenceSession=997%5F1734080301%24en1F791C8B450424BA11A92055QT3

HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/5.0
Date: Tue, 28 Jun 2005 13:51:54 GMT
ETag: "a8412d7ccb49c51:1610"
Content-Length: 0


Request/Response #2

POST /wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/GetDocWithParam HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/Get
Document?sEntry=wi00000001&sForceRefresh=Y&sOpen=&sHTMLPath=/
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: cosmos.consorta.com
Content-Length: 137
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: ASPSESSIONIDQQDRAQDA=KOLJIIDAKGCFNODBGJIPILLP;
WebIntelligenceSession=997%5F1734080301%24en1F791C8B450424BA11A92055QT3
sEntry=wi00000001&sOpen=R&sPath=N&lsS1%29+Select+Agreement+Owner=Consorta%2C
+Inc.&lsS2%29+Select+Agreement+Area%28s%29=%28ALL%29&lsCBR=-1

HTTP/1.0 200 OK
Content-Length: 939 
Content-Type: text/html


Request/Response #3

GET
/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/ExtractPDF?sEntry=wi00000001&
TS=-2138780203&sPath=/Document/agreement+index+by+agreement+area+.pdf
HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/Get
DocWithParam
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: cosmos.consorta.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDQQDRAQDA=KOLJIIDAKGCFNODBGJIPILLP;
WebIntelligenceSession=997%5F1734080301%24en1F791C8B450424BA11A92055QT3

HTTP/1.0 200 OK
Content-Length: 301131
Content-Type: application/pdf


Request/Response #4

GET
/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/ExtractPDF?sEntry=wi00000001&
TS=-2138780203&sPath=/Document/DocLinks.htm HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/bin/iswi.dll/cookie/wiqt/queryTechnique/Get
DocWithParam
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: cosmos.consorta.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDQQDRAQDA=KOLJIIDAKGCFNODBGJIPILLP;
WebIntelligenceSession=997%5F1734080301%24en1F791C8B450424BA11A92055QT3

HTTP/1.0 200 OK
Content-Length: 1059 
Content-Type: text/html


Request/Response #5

GET
/wiasp/viewers/rep.wiqt/setNewToken.asp?iventrystore=ctxdoc_docToken&entry=w
i00000001 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Referer:
http://cosmos.consorta.com/wiasp/viewers/rep.wiqt/openDocument.asp?name=Agre
ement+Index+by+Agreement+Area&doctype=rep&id=19577&repotype=0&ViewType=P&lan
g=en&skin=skin_cosmos&iventrystore=ctxdoc_docToken&mifv=n&entry=wi00000001(at)0
_wi00000001&refresh=Y&wait=N
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet
PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: cosmos.consorta.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDQQDRAQDA=KOLJIIDAKGCFNODBGJIPILLP;
WebIntelligenceSession=997%5F1734080301%24en1F791C8B450424BA11A92055QT3

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 28 Jun 2005 13:52:07 GMT
Content-Length: 19
Content-Type: text/html; Charset=UTF-8
Expires: Tue, 28 Jun 2005 13:51:07 GMT
Cache-control: private







[...]

On Tue, 28 Jun 2005 09:08:38 -0500 "Steven Vlach" <Home_Boy(at)msn.com>
wrote:
[...]
timeouts[...]
fixed,[...]
one[...]
ability of[...]
quick[...]
give[...]
application[...]
and[...]
timeout[...]
something to[...]
"expire"[...]
 In[...]
the[...]
but[...]
timeout[...]
serves up[...]
dll).[...]

Unlikely. BTW - it seems to be the other way around - 1.0 for
everything, 1.1 for the last. This casts some doubt on the "4
descriptors" idea, as 1.0 connections are closed immediately on
completion.
[...]
then[...]
seconds[...]
timeout[...]
Pound), then[...]
shed[...]
#5,[...]
client[...]
seconds.

I think I would try to lower the Server timeout. If your server is fast
enough this should cause no problems, and once the server-side
connection times out Pound will close it, as well as the client-side.
Why don't you try a "Server 5" and see if it helps?
[...]
issue.[...]
quality[...]
which[...]

Thanks for the kind words. We always appreciate getting useful user
comments, especially in such hard-to-diagnose cases.[...]

Hi Robert,
[...]


I tried changing the server timeout to 5, but the application isn't fast
enough sometimes, so I made Server 10 and set the Client 20, but the PDF
didn't generate until the client timeout (20 seconds) hit, it didn't seem to
make a difference what the serve timeout was.

[...]

Robert Segall wrote:
[...]

Robert, thanks for the insight.

I don't think the issue is one of a client-side timeout.  I can say this 
because I've seen this problem happen on 100 meg segments, with *no* 
traffic to speak of on the segment, no load on the server, the client 
not doing anything special that would cause dropped packets or a timeout 
condition.

I would not ignore even the minimal buffering the pound does -- I think 
that it may very well be where the problem resides.  That, and the "and 
abort the connection if either of them times-out" part about what you 
said -- if the server-side times out or disconnects after sending all 
its data to pound, and pound interprets this as a timed-out connection 
and tears down *both* the client and the server connections at that 
point, any data in that buffer is lost.  [I have a strong suspicion that 
sending the remaining buffered data to the client is *not* a part of the 
clean-up routine in handling such a timeout condition.] I think it's 
really an issue of the server getting done sending to pound before pound 
is done sending to the client -- that when the server disconnects from 
pound, pound disconnects from client before it sends the last of the 
buffered data, however minimal, to the client.

My suggested fix would be to verify that this is or isn't what's 
happening, and if it is what's happening, to make sure that whatever's 
buffered gets sent to the client from pound before pound does the rest 
of its clean-up.
[...]

If it is indeed a client write timeout, is there some way to retry the 
write a time or two before considering it completely dead?

Or, possibly some self-tuning client/server timeouts, over time.  If 
pound notices a number of client side timeouts, increase the client 
timeout by some value, and then decrease it over time, slowly, until you 
start seeing timeouts again, then, increase it a little bit until it 
stops.  Lather, rinse, repeat.  [And do the same on the server side.]

Thanks,
Ed

On Tue, 28 Jun 2005 20:04:34 -0400 Ed R Zahurak
<ezahurak(at)atlanticbb.net> wrote:
[...]
say[...]
and[...]
either[...]
this [...]
timeout [...]
think [...]
"and [...]
[...]
that [...]
the [...]
pound [...]
[...]

1. The total buffering is a single 2K (default) segment.
2. Pound does flush whatever it has before taking the connection down.
[...]
[...]
[...]

It already does that.
[...]
if[...]
after[...]
as[...]
[...]
you [...]

That is exactly what happens at the TCP level (try looking for a
description of TCP throttling). Personally I find it a bit over the top
to replicate that at the application level.
[...]

You may want to look at the network tuning. Most systems do quite a bit
of buffering in the IP stack (on Linux it is 128K).

What might be happening is that Pound sends the packets to the client.
These get buffered at the OS level up to 128K, and the system gets stuck
trying - and retrying - to send them, thus eventually generating a
time-out in the application (the socket is not writable within the
prescribed time limit). For example, on Linux have a look at man 7 tcp,
in particular at the tcp_abort_on_overflow option.

A possible fix for the problem you describe would be to avoid time-outs
on write. Unfortunately it would also expose you to DOS attacks - all an
attacker would have to to is to send a request and just not read the
response (while keeping the connection open). In a short time this would
exhaust your available file descriptors and/or threads.[...]