Fork me on GitHub
#funcool
<
2016-01-12
>
niwinz07:01:02

very very strange

niwinz07:01:16

subscribe uses socket behind the scenes

niwinz07:01:17

so if subscribe works, socket should work in the same way

niwinz07:01:32

if that error is happens is not because postal client

niwinz07:01:48

is because your handler returns a http response instead of doing the websocket handshake

niwinz07:01:43

There no other way to see a clear error because websocket impl in the browser just does that

kenny07:01:13

@niwinz: Not sure why the server would be returning an http response instead of the websocket handshake. This is my route: [:any "postal" (pc/router #'handlers/postal-handler)] And an example handler:

(defmulti postal-handler
          (fn [ctx frame] (select-keys frame [:type :dest])))
(defmethod postal-handler {:type :subscribe
                           :dest :reports}
  [ctx frame]
  (letfn [(on-connect [{:keys [in out] :as context}]
            (println "connect")
            (go
              (>! out (pc/frame {:value "test"}))))]
    (pc/socket ctx on-connect)))

niwinz07:01:21

Catacumba 0.10.0 does the same? Is for discard something that I have broken in the last release

niwinz07:01:29

due to memory leak fix on websocket engine

kenny07:01:33

I'll try 0.10.0 right now

kenny07:01:21

Getting the same error

niwinz07:01:14

Hmm ok, it is not related to bug fix

niwinz07:01:06

Can you paste the both lines you are using to connect to catacumba: the subscribe and the socket ?

niwinz07:01:13

(from cljs)

niwinz07:01:28

maybe the bi-directional socket does not reaches that handler

niwinz07:01:31

and reaches other...

kenny07:01:58

[instream outbus] (pc/socket client :messages) and bus (pc/subscribe client :messages) where (def client (pc/client (str (.-origin js/location) "/postal")))

niwinz07:01:07

If you want use bi-directional sockets

niwinz07:01:19

you should change the {:type :subscribe with {:type :socket

niwinz07:01:46

the error surelly is hapens because me message arribes but it does not routes to appropiate handler

kenny07:01:32

That did it simple_smile I didn't see that minor detail anywhere in the docs. Did I miss it?

niwinz07:01:06

Maybe the docs are wrong that is clearly possible

kenny07:01:50

I think it's just missing that difference. Thanks for the help! simple_smile

niwinz07:01:58

You are welcome!

mitchelkuijpers08:01:50

How do you guys do error handling with core.async channels with catacumba?

mitchelkuijpers08:01:15

something along the lines of:

(go
      (let [groups (<! groups-chan)]
        (if (instance? Throwable groups)
          (throw groups)
          (ct/delegate {:groups groups}))))))
does not seem to work because catacumba is obviously listening to the channel

niwinz08:01:30

hi @mitchelkuijpers! In my code I try to isolate the logic and corresponding possible error raising code in separate functions and in catacumba handlers just use that functions and capture posible errors and return corresponding http request with error...

mitchelkuijpers08:01:20

Aha that sounds reasonable, I don’t really see a generic solution to this problem. Maybe I should just use a promise

niwinz08:01:57

But now I see that there no way to use the generic error handling mechanism that catacumba have... with async values

niwinz08:01:46

This can be used with simple handlers. If simple handler raises an exception that error handler will be executed

mitchelkuijpers08:01:55

Yes I know we use that

niwinz08:01:20

I think that this should work in the same way with async results

mitchelkuijpers08:01:33

Maybe fun to know, we are currenlty running in production for about 3 months now with catacumba: https://marketplace.atlassian.com/plugins/nl.avisi.jira.plugins.relations-for-jira/cloud/overview

mitchelkuijpers08:01:48

Yes maybe it should but currently it doesn’t right?

niwinz08:01:09

@mitchelkuijpers: thanks for sharing! It is awesome!

niwinz08:01:44

no, at this moment it does not works, at least with core.async no...

niwinz08:01:53

It should work with manifold and with promesa (completable future)