Bug 64788

Summary: WebSocket: Connecting to localhost:8880 takes one second on Windows
Product: WebKit Reporter: Yuta Kitamura <yutak>
Component: Tools / TestsAssignee: Yuta Kitamura <yutak>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, dpranke, ojan, tkent, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 70992    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch v2 (no expectation change)
none
Patch for landing none

Yuta Kitamura
Reported 2011-07-19 02:47:08 PDT
The test seems to hung when opcode=11 on chromium-win. I don't know why. Full output: CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 3 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 4 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 5 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 6 CONSOLE MESSAGE: line 0: Unrecognized frame opcode: 7 Tests whether WebSocket ignores frames with reserved opcode. On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". Opcode 3: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 4: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 5: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 6: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 7: Test started. onopen() was called. onclose() was called. PASS closeEvent.wasClean is false Opcode 11: Test started.
Attachments
Patch (3.31 KB, patch)
2011-10-19 06:10 PDT, Yuta Kitamura
no flags
Patch v2 (no expectation change) (1.89 KB, patch)
2011-10-19 23:43 PDT, Yuta Kitamura
no flags
Patch for landing (1.92 KB, patch)
2011-10-27 22:28 PDT, Yuta Kitamura
no flags
Yuta Kitamura
Comment 1 2011-07-19 03:04:47 PDT
Marked as TIMEOUT for now. I'm trying to reproduce this.
Yuta Kitamura
Comment 2 2011-07-19 10:40:36 PDT
Okay, I figured out the cause. This timeout happens on Win-Vista-Release and Win-7-Release. Mac and Linux seem unaffected. - The test opens a WebSocket connection using the hostname "localhost" (e.g. new WebSocket("ws://localhost:8880/...")) - Resolving "localhost" returns "::1" (IPv6 loopback address), but websocketserver doesn't listen on IPv6 address. - So connect fails, but it takes about one second to fall back to IPv4. :( - The test reserved-opcodes.html opens ten new connections, which means one-second block adds up and it will take 10+ seconds to complete the test. - For release builds, the test timeout is set to 6 seconds so the test timeouts. For debug builds, the test has 12 seconds which is somewhat enough to complete the test. Replacing "localhost:8880" with "127.0.0.1:8880" will fix the problem. Using this opportunity, I'd like to replace all the occurrences of "localhost" in WebSocket tests. This should cut the layout test execution time in Vista/7 bots.
Alexey Proskuryakov
Comment 3 2011-07-19 10:47:09 PDT
Nice catch! > websocketserver doesn't listen on IPv6 address Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1.
Yuta Kitamura
Comment 4 2011-07-19 12:09:51 PDT
(In reply to comment #3) > Nice catch! > > > websocketserver doesn't listen on IPv6 address > > Can this be fixed instead? Listening on IPv6 would be consistent with our Apache setup, and thus less surprising than having a requirement to only use 127.0.0.1. I first thought this was easy, but I was wrong; pywebsocket standalone server currently does not provide dual-stack server support, and adding it seems to require unobvious amount of work. I'll ask pywebsocket folks about this, but I'm leaning towards the idea of using only "127.0.0.1:8880" and forgetting about IPv6... Maybe we could forbid the use of "localhost:8880" by adding some check to check-webkit-style.
Yuta Kitamura
Comment 5 2011-07-19 12:20:23 PDT
Another idea is to bring up two instances of pywebsocket standalone server (one for IPv4, one for IPv6) in run-webkit-websocketserver. This is not obvious, either, and IMO the amount of work does not balance with the actual gain (what we really want to test is our WebSokcet implementation, not server's IPv4/v6 dual stackness).
Alexey Proskuryakov
Comment 6 2011-07-19 12:55:56 PDT
We also need to test cross origin behavior, and the simple fact that we resolve host names.
Yuta Kitamura
Comment 7 2011-10-19 05:28:52 PDT
Dual-stack support (listening at IPv4 and IPv6 addresses simultaneously) was added to pywebsocket recently. To make use of this feature, we have to give a command-line option "--server-host localhost" to standalone.py instead of "--server-host 127.0.0.1".
Yuta Kitamura
Comment 8 2011-10-19 06:10:09 PDT
Kent Tamura
Comment 9 2011-10-19 18:10:18 PDT
Comment on attachment 111603 [details] Patch We had better land the 127.0.0.1 -> localhost change without the test_expectations.txt change , see the layout test results for a while, and then apply the test_expectations.txt change.
Yuta Kitamura
Comment 10 2011-10-19 23:43:07 PDT
Created attachment 111729 [details] Patch v2 (no expectation change)
WebKit Review Bot
Comment 11 2011-10-20 21:13:19 PDT
Comment on attachment 111729 [details] Patch v2 (no expectation change) Clearing flags on attachment: 111729 Committed r98064: <http://trac.webkit.org/changeset/98064>
WebKit Review Bot
Comment 12 2011-10-20 21:13:24 PDT
All reviewed patches have been landed. Closing bug.
Yuta Kitamura
Comment 13 2011-10-20 22:47:58 PDT
Reverted r98064 for reason: Broke Mac bots. Committed r98068: <http://trac.webkit.org/changeset/98068>
Yuta Kitamura
Comment 14 2011-10-20 23:42:24 PDT
Sounds like this is pywebsocket's problem; after newer version of pywebsocket is rolled into WebKit we will be safely land this patch again.
Yuta Kitamura
Comment 15 2011-10-27 22:24:50 PDT
New pywebsocket (with a fix) has been landed; let me try this again.
Yuta Kitamura
Comment 16 2011-10-27 22:28:07 PDT
Created attachment 112815 [details] Patch for landing
WebKit Review Bot
Comment 17 2011-10-27 22:39:32 PDT
Comment on attachment 112815 [details] Patch for landing Clearing flags on attachment: 112815 Committed r98693: <http://trac.webkit.org/changeset/98693>
WebKit Review Bot
Comment 18 2011-10-27 22:39:37 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.