Fork me on GitHub
#funcool
<
2016-03-18
>
kenny01:03:27

You should add 0.5.0 to the changelog for postal.

niwinz06:03:03

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

kenny07:03:53

@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: ratpack.handling.internal.NcsaRequestLogger@88f0f03. partial works with multimethods. Is there something happening internally that could be causing this?

niwinz07:03:28

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

niwinz07:03:44

seems that the problem comes from thre multimethod dispatch function

kenny07:03:17

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

kenny07:03:42

I don't think that would cause that error

niwinz07:03:37

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

niwinz07:03:58

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

kenny07:03:15

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))]])

niwinz07:03:21

I don't seems like related to logger

niwinz07:03:34

Oh seems like you have missed :any

niwinz07:03:43

on the first routing entry maybe?

niwinz07:03:31

Try put :any , maybe is a documentation bug

kenny08:03:21

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

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

niwinz08:03:07

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

niwinz08:03:35

About the log, it is clearly a documentation bug

kenny08:03:50

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)))

niwinz08:03:06

Are you sure that the request arrives here?

kenny08:03:36

Yes. The req is logged in the console

niwinz08:03:06

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

niwinz08:03:26

Just put a println inside and check that is executed

kenny08:03:55

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

niwinz08:03:52

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

niwinz08:03:02

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

niwinz08:03:04

this is wrong

niwinz08:03:29

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

niwinz08:03:41

let me 5 min for check that

niwinz08:03:52

hmm, no I'm wrong

niwinz08:03:58

:any accepts path also ..

niwinz08:03:50

Hmm, please try reorder your routes

niwinz08:03:00

put your assets after the postal handlers

niwinz08:03:21

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

niwinz08:03:06

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

kenny08:03:04

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?

niwinz08:03:45

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

kenny08:03:59

The routes dont like to reload though

niwinz08:03:28

the autoreloader handler also should work

niwinz08:03:47

and for that, the restart is not required

kenny08:03:48

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.
but the server is still running

niwinz08:03:59

it should be revised

kenny08:03:37

Anyways, my error is gone after restarting the repl.

niwinz08:03:45

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

kenny08:03:51

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

kenny08:03:19

Ah okay. I'll try that right now

niwinz08:03:34

the autoreloader handler does not need any server restart

niwinz08:03:03

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

niwinz08:03:33

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

kenny08:03:56

You should add that to the docs simple_smile

kenny08:03:07

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

niwinz08:03:06

This is may main ns.

kenny08:03:36

Where is catacumba?

kenny08:03:48

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

niwinz08:03:00

I will check it again

kenny08:03:15

I can create a minimum working example of the problem

niwinz08:03:35

do not worry, I need some time for check that

niwinz08:03:49

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

niwinz08:03:28

I have checked and works as expected

niwinz08:03:40

calling (start) on my repl

niwinz08:03:44

starts the server

niwinz08:03:50

and (stop) stops properly the server

kenny08:03:33

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

niwinz08:03:41

nice, thanks!

kenny08:03:40

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

niwinz08:03:27

Thanks! Let me know about anything

kenny08:03:08

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.

niwinz08:03:36

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

jetmind14:03:40

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

dialelo14:03:02

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

dialelo14:03:43

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

dialelo14:03:55

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

jetmind14:03:40

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

dialelo14:03:25

that's surprising

dialelo15:03:58

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

dialelo15:03:29

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

dialelo15:03:54

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

jetmind15:03:08

I'll try to create a patch later today

dialelo15:03:49

awesome, let me know if you run into any problems

niwinz15:03:48

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

jetmind15:03:20

and lacks any tests AFAICS simple_smile

niwinz15:03:24

sure 😞

dialelo16:03:54

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

jetmind16:03:30

Cool! Thanks for quick release!

jetmind16:03:43

and for creating the library in the first place)