lamina.core.graph.propagator: error in aleph.http.core/expand-writes

[thenwithexpandedwingshesteershisflight]

when I first connect to my website my server throws https://gist.github.com/2957594 .also happens when my browser refreshes the page

[Zach Tellman]

It looks like your response map doesn't have a :status key.

[thenwithexpandedwingshesteershisflight]

excuse my ignorance but how do I fix that ?

also I'm getting

java.net.ConnectException: Connection refused
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
    at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.connect(NioClientSocketPipelineSink.java:407)
    at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.processSelectedKeys(NioClientSocketPipelineSink.java:369)
    at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.run(NioClientSocketPipelineSink.java:285)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

when I start the server

[Zach Tellman]

What does your HTTP response look like? The Ring spec specifies that
it should at least be something like {:status 200}, with optional
:headers and :body keys. Your stack trace seems to indicate there is
no :status key.

As to the other exception, that seems to be from a client trying to
connect to an address. You say this is happening when you start up a
server?

Zach

[thenwithexpandedwingshesteershisflight]

On Saturday, June 23, 2012 8:56:23 AM UTC+10, ztellman wrote:

What does your HTTP response look like?  The Ring spec specifies that
it should at least be something like {:status 200}, with optional
:headers and :body keys.  Your stack trace seems to indicate there is
no :status key.

oddly, while trying to reproduce the error, which was occuring even when I switched tabs back and forth between my site and a random other tab, it's just gone away! suddenly just works.

 

As to the other exception, that seems to be from a client trying to
connect to an address.  You say this is happening when you start up a
server?

yes it happens when I first start the webserver with:

(defn start-webserver* []
  (start-http-server
    (->
      paths/the-paths
      (handler/site)
      (wrap-file    "./public")
      (wrap-file-info)
      (wrap-stacktrace)
      (wrap-ring-handler)
    )
    {:port 8080 :websocket true :thread-pool {}}
  )
)

- code may be out-of-date

[Paul Bostrom]

I was trying to put together an app that uses aleph and compojure together and I am seeing this same stack trace. The routes actually get loaded by the browser successfully with a 200 response, but the stacktrace gets printed out on every reload. I defined 2 compojure routes, one that returns a string, and one that explicitly returns a {:status :headers :body} map. Both generate the stacktrace. 

I created a github project with a minimal test case to reproduce it:

https://github.com/pbostrom/aleph-npe 

The relevant files are these:

https://github.com/pbostrom/aleph-npe/blob/master/project.clj 

https://github.com/pbostrom/aleph-npe/blob/master/src/npe/core.clj 

https://github.com/pbostrom/aleph-npe/blob/master/stacktrace 

[Zach Tellman]

When I run your server, and "curl localhost:8080/foo" or "curl
localhost:8080/bar", I get a response. When curling some other URL, I
get the error you post. Typically, at the bottom of a defroutes, you
have a (compojure.route/not-found "message"), because otherwise the
handler will just return nil, which throws the that error.

I'll add in some more friendly error messages when the HTTP response
isn't valid, but I don't think there's anything wrong here. Please
let me know if I've misunderstood something.

Zach

[Paul Bostrom]

Weird, apparently it only happens in Chrome (v. 21). I wonder if Chrome is requesting some other URL in the background as part of its request for foo or bar. Firefox behaves just like curl, which is the expected behavior. Well, thanks for pointing me in the right direction.

[Marc Haemmerle]

Chrome is probably trying to fetch the favicon (like most of the browsers). It could also be an issue if Chrome is probing the url in it's type-ahead..