WebPositive leaves network connections open after pageload

[kallisti5]

on hrev529.

WebPositive leaves network connections open after page load.

To test:

• Navigate to website via WebPositive
• Launch netstat -an on Web server or local box
• Notice open connections.
• After page load is complete, connections still exist as ESTABLISHED
• After closing WebPositive, connections still exist as TIME WAIT, program is listed in netstat as old pid
• Connections will change to TIME WAIT and eventually time out after a few minutes.

[kallisti5]

also, Haiku hrev37437

[anevilyak]

At least the last two points are AFAIK expected behavior as concerns TCP/IP.

[kallisti5]

Not always...

Example:

wget a remote file, after wget executes and quits there are no open network connections.

ESTABLISHED should transition to TIME WAIT / CLOSE WAIT and CLOSE immediately if everything goes well.

[kallisti5]

I was a little off in my previous post,

The established do transition to to close-wait while the program is still running, it just takes a really,really,really, long time. Still though, we should be a little neater with our sockets and kinder to our servers ;)

[stippi]

Can you repeat the test results with a cURL based program perhaps?

[kallisti5]

Curl works as expected:

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:52:15 CDT 2010

!!! EXECUTE curl http://server:3000 on Haiku box

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:52:17 CDT 2010
tcp      137      0 10.21.16.113:3000       10.21.17.70:40121       ESTABLISHED

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:52:23 CDT 2010
tcp        0      0 10.21.16.113:3000       10.21.17.70:40121       ESTABLISHED

!!! COMPLETE curl on Haiku box

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:52:27 CDT 2010

haiku # date; netstat -n | grep serverip
Mon Jul 12 12:52:29 CDT 2010
tcp        0      0 10.21.17.70:40121       10.21.16.113:3000       time-wait       262

[kallisti5]

With Web+:

!!! EXECUTE page load of http://server:3000 on Haiku box with Web+

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:57:16 CDT 2010
tcp      446      0 10.21.16.113:3000       10.21.17.70:40136       ESTABLISHED


server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:57:28 CDT 2010
tcp        0      0 10.21.16.113:3000       10.21.17.70:40136       ESTABLISHED
tcp      428      0 10.21.16.113:3000       10.21.17.70:40190       ESTABLISHED
tcp      438      0 10.21.16.113:3000       10.21.17.70:40199       ESTABLISHED
tcp      424      0 10.21.16.113:3000       10.21.17.70:40175       ESTABLISHED


server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:57:51 CDT 2010
tcp      437      0 10.21.16.113:3000       10.21.17.70:40136       ESTABLISHED
tcp      428      0 10.21.16.113:3000       10.21.17.70:40190       ESTABLISHED
tcp        0      0 10.21.16.113:3000       10.21.17.70:40199       ESTABLISHED
tcp        0      0 10.21.16.113:3000       10.21.17.70:40175       ESTABLISHED

!!! PAGELOAD in Web+ Complete

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:58:21 CDT 2010
tcp        0      0 10.21.16.113:3000       10.21.17.70:40136       ESTABLISHED
tcp        0      0 10.21.16.113:3000       10.21.17.70:40190       ESTABLISHED
tcp        0      0 10.21.16.113:3000       10.21.17.70:40199       ESTABLISHED
tcp        0      0 10.21.16.113:3000       10.21.17.70:40175       ESTABLISHED

!!! KILL Web+

server # date; netstat -na  | grep 10.21.17.70
Mon Jul 12 12:58:43 CDT 2010

haiku # date; netstat -na | grep 10.21.16.113 (serverip)
Mon Jul 12 12:58:46 CDT 2010
tcp        0      0 10.21.17.70:40136       10.21.16.113:3000       time-wait       220
tcp        0      0 10.21.17.70:40175       10.21.16.113:3000       time-wait       220
tcp        0      0 10.21.17.70:40190       10.21.16.113:3000       time-wait       220
tcp        0      0 10.21.17.70:40199       10.21.16.113:3000       time-wait       220

[stippi]

Thanks for running these tests! I've already fixed one problem in the WebKit cURL backend which resulted from WebPositive using/linking a newer libcurl compared to what the code was written against. So maybe this is another instance. One should consume the current cURL developer documentation and compare that to what's happening in the backend. I have no idea when I will have time for this.

[kallisti5]

Close for now. The services kit would fix this issue someday.. I also haven't seen this exact issue for quite some time.