Connecting to a Drawbridge Ring handler fails with ArityException

[Eero Helenius]

I have a web app with a Drawbridge Ring handler endpoint athttp://localhost:8000/repl.

I tried connecting to it like this:

(require '[nrepl.core :as nrepl]
         '[drawbridge.client :as client])

(with-open [conn (nrepl/url-connect "http://localhost:8000/repl")]
    (-> (nrepl/client conn 1000)
        (nrepl/message {:op "eval" :code "(+ 2 3)"})
        nrepl/response-values))

That yields this exception:

ArityException Wrong number of args (0) passed to: client/ring-client-transport/read--2318  clojure.lang.AFn.throwArity (AFn.java:429)

It looks like the read function in the Drawbridge client expects a single argument (timeout) while the calling code in nrepl.transport doesn't supply any.

[Bozhidar Batsov]

@mallt Can we use (abuse :-)) your excellent debugging skills on this one?

[Tijs Mallaerts]

@eerohele Could you specify which versions of nrepl and drawbridge you are using in your example? Thanks!

[Bozhidar Batsov]

@mallt I think this happens with nREPL 0.4.5 and drawbridge 0.1.3.

You'll just need a "getting started with ring" type of application to be able to reproduce this. Probably we should bundle one such app with the project, so it's easier to test it. Or even better - we should write some tests that simply boot a ring app and test sending a few messages over http.

[Eero Helenius]

drawbridge-28.zip contains a minimal repro.

You can run it like this, for example:

$ clj -Srepro -m app.core

[Bozhidar Batsov]

Btw, if I had to guess I'd say I broke this here 1f918e2 (or in the previous commit). Generally fn-transport is the way to go, but maybe I messed something up. I recall I was just doing mechanical updates without actually running the code due to lack of time on my end.

[Tijs Mallaerts]

That seems to cause the problem indeed, the recv-fn of the FnTransport is called with a timeout, whereas the transport-read of the fn-transport is called without args.

I'm not sure how to deal with this however, do we need to set a fixed timeout to be able to use the fn-transport?

[Bozhidar Batsov]

I guess you can just FnTransport directly for now and we can also file another ticket to make fn-transport a bit more flexible. No idea why the two APIs are out of sync.

[Tijs Mallaerts]

Ok perfect thanks, I'll submit a PR for this.

[Tijs Mallaerts]

As a side note, when changing to the FnTransport., my CIDER complains with an illegal argument exception:

2. Unhandled clojure.lang.Compiler$CompilerException
Error compiling src/drawbridge/client.clj at (48:5)

1. Caused by java.lang.IllegalArgumentException
Unable to resolve classname: FnTransport

Is this expected? Otherwise I'll file a ticket for it in the CIDER repo. :)

Thanks!

[Bozhidar Batsov]

Ops, I read this only after cutting a new release. That's definitely a problem. I guess the record has to be imported. I think this is the reason I opted for the fn-transport last time around.

[Tijs Mallaerts]

Ok I see, my bad, I'll submit a new PR for that.

[Bozhidar Batsov]

@eerohele Please, try 0.1.5. I think we finally fixed this.

[Eero Helenius]

(let [server (server/run-server (handler/site #'app) {:port 51235})]
    (println (http/get "http://localhost:51235/echo"))
    (println (with-open [conn (nrepl/url-connect "http://localhost:51235/repl")]
               (-> (nrepl/client conn 1000)
                   (nrepl/message {:op "eval" :code "(+ 2 3)"})
                   nrepl/response-values)))
    (server))
;;=>[5]

It works — thanks!

Would you be open to a PR for a basic Ring app that tests basically that the code snippet above works? If so, I could try to put one together.

[Tijs Mallaerts]

Yes that would be great! Thanks!

That would then solve #24 as well. :)