Re: [WebDNA] Re: Hard-coded db write delay when running certain code?

This WebDNA talk-list message is from

2011

It keeps the original formatting. numero = 106229
interpreted = N
texte = I just tried again and quickly did a copy of the cookie (this time=20[/!]Cookie: wpid=3D%2D101&id=3D1136&cookies=3Dtrue; =ASPSESSIONIDSSDRADTD=3DMCCLABFDBGKNJAAHIFIJMLIO; =ASPSESSIONIDSSDRADTD=3DMCCLABFDBGKNJAAHIFIJMLIO[crlf][!]and reloaded the page almost immediately: i got the same[grabbed] with your js time counter and nothing else, for several =minutes.I would not be able to check your code but i am pretty sure it comes =neither from [append] nor [tcpconnect]. I will retest tcpconnect and =double check the timeout.- chrisOn Jan 31, 2011, at 15:41, Kenneth Grome wrote:> > To me, it sounds like a tcpconnect timeout (150 seconds)> So far this seems to make more sense than any other theory, except =that it's a 140 second interval between db writes, not 150 seconds. Are =you sure that WebDNA's tcpconnect timeout is 150 seconds?> I guess it is possible that the tcpconnect receives all the data from =the remote server in 1-2 seconds, then it just sits there for the next =138-139 seconds waiting for the timeout to expire before writing to the =db. This might very well cause the timestamps to be exactly 140 seconds =apart given the way my code is written and runs.> Note that I've tried running my code with (and without) keep-alive =enabled and it does the same thing either way, so I don't think that the =keep-alive header is keeping the connection open that long. Keep-alive =is only set to 115 and that's shorter than tcpconnect's 150 (or 140) =second timeout ... so it looks like the connection is being held open by =WebDNA.> But my tcpconnect headers are the exact same headers that Firefox is =sending when I request the remote page manually in my browser, so =theoretically the remote server cannot tell the difference between my =Firefox requests and WebDNA's tcp requests. Yet something is causing =the 140 second delay I'm seeing when I run my tcpconnect, and no such =delay is present when I use Firefox directly, so clearly there *IS* a =difference between Firefox and tcpconnect. I'm just not sure what it is =at this point ...> :(> I just looked at the online docs and unfortunately I don't see any way =to change the default tcpconnect timeout. Is there an optional =parameter for the tcpconnect timeout that is undocumented? If so I =could try to override tcpconnect's built-in 150 second timeout, and if =the "time between appends" changes along with the timeout change, I =think we can be relatively certain that this problem comes from WebDNA's =tcpconnect timeout ...> Sincerely,> Kenneth Grome> --------------------------------------------------------- This message =is sent to you because you are subscribed to the mailing list . To =unsubscribe, E-mail to: archives: =http://mail.webdna.us/list/talk@webdna.us Bug =Reporting:support@webdna.us Associated Messages, from the most recent to the oldest:

Re: [WebDNA] Hard-coded db write delay when running certain code? (christophe.billiottet@webdna.us 2011)
[WebDNA] Hard-coded db write delay when running certain code? (Kenneth Grome 2011)

I just tried again and quickly did a copy of the cookie (this time=20[/!]Cookie: wpid=3D%2D101&id=3D1136&cookies=3Dtrue; =ASPSESSIONIDSSDRADTD=3DMCCLABFDBGKNJAAHIFIJMLIO; =ASPSESSIONIDSSDRADTD=3DMCCLABFDBGKNJAAHIFIJMLIO[crlf][!]and reloaded the page almost immediately: i got the same[grabbed] with your js time counter and nothing else, for several =minutes.I would not be able to check your code but i am pretty sure it comes =neither from [append] nor [tcpconnect]. I will retest tcpconnect and =double check the timeout.- chrisOn Jan 31, 2011, at 15:41, Kenneth Grome wrote:> > To me, it sounds like a tcpconnect timeout (150 seconds)> So far this seems to make more sense than any other theory, except =that it's a 140 second interval between db writes, not 150 seconds. Are =you sure that WebDNA's tcpconnect timeout is 150 seconds?> I guess it is possible that the tcpconnect receives all the data from =the remote server in 1-2 seconds, then it just sits there for the next =138-139 seconds waiting for the timeout to expire before writing to the =db. This might very well cause the timestamps to be exactly 140 seconds =apart given the way my code is written and runs.> Note that I've tried running my code with (and without) keep-alive =enabled and it does the same thing either way, so I don't think that the =keep-alive header is keeping the connection open that long. Keep-alive =is only set to 115 and that's shorter than tcpconnect's 150 (or 140) =second timeout ... so it looks like the connection is being held open by =WebDNA.> But my tcpconnect headers are the exact same headers that Firefox is =sending when I request the remote page manually in my browser, so =theoretically the remote server cannot tell the difference between my =Firefox requests and WebDNA's tcp requests. Yet something is causing =the 140 second delay I'm seeing when I run my tcpconnect, and no such =delay is present when I use Firefox directly, so clearly there *IS* a =difference between Firefox and tcpconnect. I'm just not sure what it is =at this point ...> :(> I just looked at the online docs and unfortunately I don't see any way =to change the default tcpconnect timeout. Is there an optional =parameter for the tcpconnect timeout that is undocumented? If so I =could try to override tcpconnect's built-in 150 second timeout, and if =the "time between appends" changes along with the timeout change, I =think we can be relatively certain that this problem comes from WebDNA's =tcpconnect timeout ...> Sincerely,> Kenneth Grome> --------------------------------------------------------- This message =is sent to you because you are subscribed to the mailing list . To =unsubscribe, E-mail to: archives: =http://mail.webdna.us/list/talk@webdna.us Bug =Reporting:support@webdna.us christophe.billiottet@webdna.us

DOWNLOAD WEBDNA NOW!

Re: [WebDNA] Re: Hard-coded db write delay when running certain code?

2011

Top Articles:

Related Readings: