NPE in repl-client-js

[sritchie]

This happens on a page reload every so often, and I can't recover:

java.lang.NullPointerException
    at clojure.core$deref_future.invoke(core.clj:2108)
    at clojure.core$deref.invoke(core.clj:2129)
    at cemerick.austin$repl_client_js.invoke(austin.clj:143)
    at cemerick.austin$send_repl_client_page.invoke(austin.clj:157)
    at cemerick.austin$eval5899$fn__5901.invoke(austin.clj:268)
    at clojure.lang.MultiFn.invoke(MultiFn.java:227)
    at cemerick.austin$handle_request.invoke(austin.clj:276)
    at cemerick.austin$create_server$reify__5780.handle(austin.clj:24)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80)
    at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:677)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:649)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)

[cemerick]

Hrm, I'm not sure how that could ever happen. Is the affected project public so I can take a look?

[sritchie]

unfortunately no, but my workflow was to run the following:

(def repl-env
    (reset! cemerick.austin.repls/browser-repl-env
            (cemerick.austin/repl-env)))

  (cemerick.austin.repls/cljs-repl repl-env)

Then disconnect with :cljs/repl, then reconnect again with

  (cemerick.austin.repls/cljs-repl repl-env)

[cemerick]

I think you mean :cljs/quit?

If you do that, then REP Loop will stop, which causes the environment to be teared down. In Austin, this translates into the session being dissoc'ed from the global map. This explains the NPE, though of course it's a horrible (lack of) error message!

There's not a lot that Austin can (or should, I think) do differently here (error messages aside). :cljs/quit really has only one meaning w.r.t. ClojureScript REPLs; and, actually, not quitting Austin REPLs is technically a memory leak (since it's the only signal it has to drop sessions, though you'd need many thousands of discarded Austin REPL sessions to actually cause any problems).

Re: workflow, why are you quitting and then attempting to "reconnect"? Is it so you can move back and forth between Clojure and ClojureScript? If so, I'd suggest having dedicated REPL sessions; one for Clojure, and perhaps many for each ClojureScript runtime. Your nREPL client should have a "clone session" operation that will allow you to create the latter from the former at any time without creating multiple connections to the nREPL backend…

[sritchie]

It's the latter - I was trying to get back to the main repl and reboot, since I was getting SocketClosedException (or something phonetically similar, working from memory) on certain page reloads when the browser repl tried to reconnect. I'll try cloning my nrepl (now cider, I guess?) session and report back if I can repeat any recreations of that bug.

Thanks, Chas! Austin is fantastic. I pushed my first Clojurescript code out to master yesterday; Austin makes the repl experience really delightful. This is a feeling I've been chasing for some time.

[cemerick]

Sounds unfriendly. If you can replicate the exception, I'd love to look at it. If you ever do want to get a fresh REPL, you have to quit, create and reset! the REPL environment, and then start it up again via cljs-repl.

Glad you've found it useful so far, despite the sharp edges. I'll get a better error message in there for the post-quit reconnection failure shortly.

[sritchie]

Great, good to know. So the repl-environment is hosed once someone disconnects... makes sense, and a good error message should clear that up. I'll add some docs to my internal project.

[cemerick]

@sritchie Did you end up verifying that your emacs config was somehow provoking your Austin troubles?

[sritchie]

No, even a slim config ended up flaming out. Bumping Xmx delayed the issue, but it still arrived.— Sent from Mailbox for iPhone

On Wed, Feb 12, 2014 at 5:24 AM, Chas Emerick notifications@github.com wrote:

@geraldodev no, that looks very different; interesting error condition there. Could you open a new issue?

@sritchie Did you end up verifying that your emacs config was somehow provoking your Austin troubles?

Reply to this email directly or view it on GitHub: https://github.com/cemerick/austin/issues/22#issuecomment-34863724

[cemerick]

Closing this; the original issue is now embodied in #51.