You should add 0.5.0 to the changelog for postal.

I will do it today. Additionally I will updare its dependencies ;)

@niwinz: I am trying to setup a postal handler like so: (pc/router (partial postal-handler !db)), however, I am getting an error when a client tries to connect No method in multimethod 'attach-route' for dispatch value: [email protected]. partial works with multimethods. Is there something happening internally that could be causing this?

It seems like your dispatch funcion in the multimethod expect somethig different for first parameter

seems that the problem comes from thre multimethod dispatch function

(defmulti postal-handler (fn [_ _ frame]
                           (select-keys frame [:type :dest])))

I don't think that would cause that error

oh, I'm wrong. the error is happening in other side...

is on attach-route multimethod.. (catacumba internals).

Right

If it's any help, here are my routes:

(ct/routes
    [[(misc/log)]
     [:any (misc/autoreloader)]
     [:error all-error-handler]
     [:assets "" {:dir     "target"
                  :indexes ["index.html"]}]
     [:any "db" (pc/router (partial postal-handler !db))]])

:S

I don't seems like related to logger

Oh seems like you have missed :any

on the first routing entry maybe?

Do I need it? Doesn't have it here: https://funcool.github.io/catacumba/latest/#request-logging

Try put :any , maybe is a documentation bug

Sorta worked. Old error is gone. Client is having problems connecting:

WebSocket connection to '' failed: Error during WebSocket handshake: Unexpected response code: 200

now, with that error, just check the handler that dispatches that request and ensure that it handshakes to websocket

About the log, it is clearly a documentation bug

Yup

thanks!!

Not sure why the handler isn't dispatching correctly though.. This is all the code atm:

(defmulti postal-handler (fn [_ _ frame]
                           (println "here")
                           (select-keys frame [:type :dest])))

(defmethod postal-handler {:type :subscribe
                           :dest :db}
  [!db ctx frame]
  (letfn [(on-connect [{:keys [in out]}]
            (println "connected!"))]
    (pc/socket ctx on-connect)))

Are you sure that the request arrives here?

Yes. The req is logged in the console

The request is logged but you can't be sure that the request is properly dispatched to this implementation.

Just put a println inside and check that is executed

Ah, I misunderstood the question. No, it does not get to the handler

Hmm, the (println "here") is executed?

No

0.o

Ok, I see

In the routers definition, you have [:any "path" (pc/postal....]

this is wrong

it should be [:prefix "path" [:any (pc/postal ...]]

let me 5 min for check that

hmm, no I'm wrong

:any accepts path also ..

Hmm, please try reorder your routes

put your assets after the postal handlers

Seems like the assets as does not have path is catching all requests

The router is a pipeline, if you put less restrictive rules on top, them will not allow pass requests down...

Wait... My debugging may be incorrect. I have been stopping and restarting the server but I just restarted the repl and I saw a new "stopping server..." print out. I know calling (.stop srvr) used to stop the server but has a Catacumba update changed this?

no, you should use something like reloaded workflow for load new changes

The routes dont like to reload though

the autoreloader handler also should work

and for that, the restart is not required

Also, I just verified this... I called (.stop srvr) and the log printed

25286 [nREPL-worker-0] INFO ratpack.server.RatpackServer - Stopping server...
25307 [nREPL-worker-0] INFO ratpack.server.RatpackServer - Server stopped.

0.o

https://github.com/funcool/catacumba/issues/51

it should be revised

Anyways, my error is gone after restarting the repl.

@kenny: for use properly the autoreloader handler, you should define the handlers as vars, and pass that vars references to the routes.

I only got that error because it was running the old version of the server 😛

Ah okay. I'll try that right now

the autoreloader handler does not need any server restart

but as I have said previously, only works if you pass var references instead of handler instances directly.

About the stop the server, seems very strange because in my own projects, with reloaded workflow, it stops correctly :S

You should add that to the docs

Hmm.. Then how is my project different? You are running in the repl?

https://github.com/uxbox/uxbox-backend/blob/master/src/uxbox/main.clj

This is may main ns.

Where is catacumba?

https://github.com/uxbox/uxbox-backend/blob/master/src/uxbox/frontend.clj

Ah. Hmm.. Calling stop works in the repl?

yes

I will check it again

I can create a minimum working example of the problem

do not worry, I need some time for check that

I'm currently on my office time and I don't have time for it

Okay

I have checked and works as expected

calling (start) on my repl

starts the server

and (stop) stops properly the server

I will create a sandbox test and see if something else is up

nice, thanks!

@niwinz: This behaviour is not happening in my sandbox environment. Must be something special about my current project. Will dive deeper into it tomorrow...

Thanks! Let me know about anything

Will do. BTW, regarding beicon and Clojure. Have you looked at using RxJava for the clojure implementation? I believe it can properly handle back pressure.

Unfortunatelly, not. I did't have time for it

Hi all! Is my understanding correct that htturr does not support https (at least on a node.js)? Or am I missing something?

now that you mention it I see that if you want an HTTPS client you have to require("https") instead of require("http")

and the node client requires the http one https://github.com/funcool/httpurr/blob/master/src/httpurr/client/node.cljs#L7

if the HTTPS client supports HTTP too I'm happy to accept a patch with the change

otherwise i can make the http module used by the client a dynamic var, similar to Xhr's client's *xhr-impl*

I'm not sure if HTTPS client supports HTTP (I'm not very familiar with node) but I suspect you must choose one of them depending on url

that's surprising

if that's the case we can make the http module a dynamic variable

or inspect the URL to see which protocol we're using and use the right module

happy to merge a patch with these changes, otherwise maybe i can address it during the weekend

I'll try to create a patch later today

awesome, let me know if you run into any problems

In fact, the node client requires a great revision, because is the "less used" and less maintained

and lacks any tests AFAICS

sure 😞

Sent a pull request https://github.com/funcool/httpurr/pull/6

nice, just merged it and pushed 0.5.0-SNAPSHOT to clojars with the changes; thanks @jetmind!

Cool! Thanks for quick release!

and for creating the library in the first place)