This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-18
Channels
- # admin-announcements (59)
- # beginners (5)
- # boot (99)
- # cider (9)
- # clojure (207)
- # clojure-czech (1)
- # clojure-dev (28)
- # clojure-france (3)
- # clojure-italy (1)
- # clojure-japan (22)
- # clojurescript (234)
- # core-async (12)
- # datascript (1)
- # datomic (60)
- # funcool (137)
- # hoplon (18)
- # instaparse (2)
- # jobs (2)
- # ldnclj (42)
- # ldnproclodo (3)
- # liberator (13)
- # off-topic (21)
- # onyx (2)
- # re-frame (5)
- # reagent (12)
- # ring-swagger (5)
- # testing (17)
Cool a funcool channel! 😁
Can I only return a manifold deferred as body in a response but not as a return value?
So I can do this https://funcool.github.io/catacumba/latest/#body-as-deferred-manifold
but not:
(d/chain (jira-api/get-user-groups host user-key)
#(http/ok %))
(defn my-async-handler
[context]
(let [result (d/future (Thread/sleep 1000) "hello world")]
(d/chain result
#(http/ok & {"content-type" "text/plain"}))))
the second one is more obvious
I have a handler in my chain that checks some authorization and does a call with aleph and I would like that to be async
Yeah I checked the code that seems to be the issue
because catacumba says
2015-08-18 16:11:58,966 WARN [r.s.i.NettyHandlerAdapter] No response sent for GET request to /api/1.0/companies (last handler: catacumba.impl.handlers$eval17761$fn$reify__17763)
Yeah, I'll take a stab at it
Would you like a pull request for that?
Seems that the implementation of deffered for body handling not will work as you expect
True, I want to delegate or return a forbidden
Give me some time for finish that I'm currently working on, and later I will try to fix this inconsistences
Thanks @niwinz much appreciated
Were deploying our app next week with catacumba!
Sure will keep you posted, we are building an atlassian connect addon with it. It is in it's very early stage http://addons.avisi.com/relationsforjira/
Having a lot of fun with catacumba it's pedestal with docs
yes I think so let me double check it for you
(d/on-realized d
(fn [x] (println "success!" x))
(fn [x] (println "error!" x)))
Ok, nice! I will modify almost all implementation of IResponseHandler for async value for make it consistent
Yeah nice
Then you can basically make a non blocking chain of handlers ^^
The 0.6.0-SNAPSHOT is published with that inconsistences fixed and with more tests for that use cases
Yes thnx @niwinz
Ill trying it out as we speak
restarting the repl....
ratpack.exec.UnmanagedThreadException: Operation attempted on non Ratpack managed thread 'aleph-pool-1-2'
Aha I do a call with aleph to a webservice and then process the result
so I should put this in another or a new deferred
or a promise or whatever
Hmm very weird
at ratpack.exec.internal.ThreadBinding$$Lambda$99/1786206212.get(Unknown Source)
Hmm I'll see if I can create a very small example
(defn example
[context]
(d/chain
(http/get "")
:body
#(cthttp/ok % {:Content-Type "plain/text"})))
[manifold.deferred :as d]
[aleph.http :as http]
[catacumba.http :as cthttp]
Also gives
ratpack.exec.UnmanagedThreadException
yess threadlocals the root of all evil
I know, but ratpack tries to use them for control from that threads the response is written
I could also
If it's only a aleph error I could also switch to another http lib
But aleph is the only async lib I know of
I don't want condition your code because catacumba does not handles well this situation.
Yeah me neither
If I think of something I'll let you know
Really?
Ow lol forgot todo (reset) ...
I suspect that in some previous steps to that handler something goes out of the ratpack managed threads
I call this function:
(defn get-user-groups
[host user-key]
(-> (get host "/rest/api/2/user" {:query-params {:key user-key
:expand "groups"}})
(d/chain (fn [{:keys [body]}]
(let [groups (-> body
bs/to-string
(json/decode true)
:groups
:items)]
(mapv :name groups))))
(d/catch (fn [e]
(log/error e "Error occured while retrieving user" user-key)
[]))))
and then do a chain in the handler on this result
so something along the lines of:
`
(d/chain (get-user-groups ...) (if (foo) (forbidden) (delegate)))
https://github.com/funcool/catacumba/blob/master/src/clojure/catacumba/impl/handlers.clj#L233
(let [conn (database/context->connection context)
host (:host context)
permitted-groups (set (mapv :permissions/group-name
(database/get-permissions conn host)))
user-key (:userKey (:user context))
user-groups (jira-api/get-user-groups host user-key)]
(d/chain user-groups
set
(fn [_] (ct/delegate context)))))
Aha and then I am int he wrong thread
That makes alot of sense
@niwinz: That's what I am currently doing already
Thanks for all your help dude
@mitchelkuijpers: I just uploaded an other version to clojars (under 0.6.0-SNAPSHOT) that should allow the fully async delegation process
the only restriction is that the return value of (ct/delegate ctx) should be the response (synchronous or asynchronous) of the handler.
As I can see on your last code pasted here in channel, this is just how you are using. You are just return a deferred with the value of the execution of (ct/delegate...) so this code now should works as expected in fully asynchonous way.
The curren implementation removes some speed improvements introduced previously but is just for fix this issue. I think that for the next version I will have time for fix it definitivelly with proper optimizations.
You Rock @niwinz will try it out tomorrow. Will also check out your code which fixes this, I am curious how you did it 👍
Take care that (ct/delegate...) function call signature is changed. It's no longer accepts context as first parameter. Now the ct/delegate is just a special response instead of special case.