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 = 106227
interpreted = N
texte = --Boundary-01=_HRvRNBzhuSHNV7EContent-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: 7bit> 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--Boundary-01=_HRvRNBzhuSHNV7EContent-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: 7bit

> 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

--Boundary-01=_HRvRNBzhuSHNV7E-- 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)

--Boundary-01=_HRvRNBzhuSHNV7EContent-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: 7bit> 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--Boundary-01=_HRvRNBzhuSHNV7EContent-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: 7bit

> 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?

Sincerely,

Kenneth Grome

--Boundary-01=_HRvRNBzhuSHNV7E-- Kenneth Grome

DOWNLOAD WEBDNA NOW!

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

2011

Top Articles:

Related Readings: