Intermittent failure of repl connection

[deg]

Most of the time, I can't get browser-connected-repl-sample to work. But, I have seen it work occasionally, so I know my config is not totally wedged. Unfortunately, I haven't been able to get it to work at all recently, so I can't compare working vs broken cases to see what's going wrong.

The problem seems to be that the long-poll gets answered and the next one is not posted.

Until just now I've been using only Chrome, and the problem occurred most of the time. I just installed and tried with Firefox and things work on the first attempt. So, the problem may be chrome specific. I'll continue to debug, but just wanted to check in to see if this rings any bells.

[cemerick]

Any kind of transient failure like this very often ends up being cruft having built up in various directories that the compiler / REPL use to store intermediate bits. Try blowing away out, .repl, and target.

[deg]

I tried that. Also tried with a freshly pulled copy of the Austin repo.

With Chrome, I've seen no successful attempts for the past day's focused testing, and very few successes before that.

With Firefox, things are consistently working (though only a few attempts so far).

I will continue testing later today (guess I'll start by clearing Chrome's state). So far, all I can say for sure is that I'm seeing a different pattern of network traffic when I compare Firefox with the failing Chrome cases.

Can you reliably run this in Chrome?

Actually, to be precise, I'm running Chromium: "Version 28.0.1500.71 Ubuntu 12.10 (28.0.1500.71-0ubuntu1.12.10.1)"

[cemerick]

Chrome is actually my default catch-all test browser (including hosting most of my ClojureScripting). I don't think I've ever run chromium.

[deg]

1. Ok, I'll poke further. I may have time later today; otherwise it won't be for a few days. I'll install chrome on this VM, and maybe try chromium on another machine. Hard to imagine that it's a chrome vs chromium problem, but guess I gotta at least rule out that possibility.

2. Argh, Github did not post my last message here. (I'm doing something wrong; this has happened a few times. Probably losing focus between multiple VMs, single-clicking on comment, and not noticing that nothing happens before blindly closing the window. Or something else...). Anyway, I had detailed the differences in network traffic between the failing and working case. Basically, on a refresh after reset!'ing the repl, the first four request are the same; the fourth returning a few lines of Javascript referring to print-fn). But, the failing browser has no fifth request, while the working browser POSTs a fifth request which becomes a long-poll.

[deg]

Got it!

The issue was not chrome vs chromium; that would have been too bizarre. But, at least that set me in the right direction.

The real issue was that I was logged in to my Google account, which dragged along all my chrome/chromium extensions. Once I realized that, it was easy to isolate the culprit: the Google Voice extension.

A frustrating SOB of a bug; who-woulda-thought to look there. But, at least I'm good now.

Do you want me to submit a patch with a warning line for the README.md?

[cemerick]

That is really strange. A warning is worthwhile, but I'd like to know what about the extension was interfering; presumably whatever it's doing isn't unique among chrome extensions…?

[deg]

I agree 100%. I can do the first steps of describing the visible breakage, but I don't have the tools to poke deeper; I'm less than a rank novice at Chrome's architecture and know zero about Google Voice internals.

Do you know anyone who might have a good handle on attacking this kind of problem?

Of course, it would also be extremely useful for someone else to verify this bug, and make sure that it's not an interaction of GV with something else in my environment. Do you have the time to do so?

[deg]

Some more info which may mean more to you than to me:

In both cases (Chromium with Google Voice enabled or disabled, running a clean browser-connected-repl-sample), the first four packets are the same:

• Packet 1 - GET the web page html
• Packet 2 - GET app.js
• delay for a few hundred msec
• Packet 3 - GET http://localhost:59587/6678/repl?xpc={"cn":"Igg62CCsNV","tp":null,"osh":null,"ppu":"http://localhost:8080/robots.txt","lpu":"http://localhost:59587/robots.txt"} (URLencoded, of course)
• delay for another few hundred msec
• Packet 4: POST, as follows:

Request URL:http://localhost:59587/6678/repl
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:42
Content-Type:application/x-www-form-urlencoded;charset=UTF-8
Cookie:ring-session=b8d6c869-776d-47d3-93af-e339aa21e0a2; chat-id=336c3fb2-d577-4ccf-ba5b-f19e2cf0b898
Host:localhost:59587
Origin:http://localhost:59587
Referer:http://localhost:59587/6678/repl?xpc=%7B%22cn%22%3A%22Rtr72TADp5%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2Flocalhost%3A8080%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2Flocalhost%3A59587%2Frobots.txt%22%7D
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.71 Chrome/28.0.1500.71 Safari/537.36
Form Dataview sourceview URL encoded
{:type :ready, :content "ready", :order 1}:
Response Headersview source
Content-length:120
Content-Type:text/javascript; charset=utf-8
Date:Mon, 30 Sep 2013 07:28:09 GMT
Server:ClojureScript REPL

With response

goog.provide('cljs.user');
goog.require('cljs.core');
cljs.core._STAR_print_fn_STAR_ = clojure.browser.repl.repl_print;

Then, the working case (GV disabled) immediately sends a fifth packet:

Request URL:http://localhost:59587/6678/repl
Request Headersview source
Content-Type:application/x-www-form-urlencoded;charset=UTF-8
Origin:http://localhost:59587
Referer:http://localhost:59587/6678/repl?xpc=%7B%22cn%22%3A%22Igg62CCsNV%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2Flocalhost%3A8080%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2Flocalhost%3A59587%2Frobots.txt%22%7D
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.71 Chrome/28.0.1500.71 Safari/537.36
Form Dataview sourceview URL encoded
{:type :result, :content "{:status :success, :value \"function (a) {\\n  var b : cljs.core.deref.call(null, clojure.browser.repl.xpc_connection);\\n  return cljs.core.truth_(b) ? clojure.browser.net.transmit.call(null, b, \\\"\\\\ufdd0:print\\\", cljs.core.pr_str.call(null, a)) : null\\n}\"}", :order 2}

This, of course, sits in the long-poll with no response until I evaluate something in the REPL.

The failing case never sends this packet at all.

[smiler]

This (goofy) extension breaks in the same way: https://chrome.google.com/webstore/detail/dictionary-of-numbers/ahhgdmkmcgahbkcbmlkpmmamemlkajaf

[cemerick]

With a second confirming case, I'm happy to have the warning in the patch on gh-18 shown in the main README as well, in the " Using other browser runtimes" section.

[cemerick]

Hoping that this is related to the use of CrossPageChannel, and therefore resolved by #50.