Fork me on GitHub
#yada
<
2017-04-03
>
korny08:04:05

Is there a quick way to diagnose schema failures? Dump them to a log or something? I’m running an external test against a yada server, it’s failing because something they send me doesn’t match my schema, but I’m not sure what.

korny08:04:29

I know there are errors sent back to the caller in the http response body, but I don’t have an easy way to see that.

borkdude09:04:17

@korny Hmm, doesn’t Yada send an {:errors …} thingie back, like compojure-api?

korny09:04:41

It probably does somewhere, but that’s all in magic code inside my {:methods {:post {:parameters {:body my-schema} … } } resource - I guess I’m not sure where to hook in error checking myself. Anyway I’m going to leave it until after work, will give it a better look then

korny09:04:55

Actually I’m also tempted to follow Postel’s law, and just get rid of the schema check entirely. It’s nice as a proof of concept to say “hey, we can check schemas” but TBH I’m not keen on writing code which type checks incoming data too rigorously.

mccraigmccraig10:04:15

@korny schema checks get more useful the bigger your api gets - we have shared client/server schema and it's brilliant for flushing out bugs after api changes (not as good as static checks, but pretty good for clojureland), particularly in development. it's a bit more ambiguous in production, since it can make older clients unnecessarily incompatible with newer servers

borkdude11:04:21

I have an async question. Consider the following async endpoint:

;; [aleph.http :as http]
;; [manifold.deferred :as d]

["/async"
         (yada/resource
          {:produces "application/json"
           :methods
           {:get
            {:response (fn [ctx]
                         (d/chain (http/get "")
                                  (fn [resp]
                                    {:result (slurp (:body resp))})))}}})]
Behind localhost:3000/example is an endpoint that has a (Thread/sleep 5000). It runs in a different process. I’m firing 20 requests to the Yada endpoint. What I expect now is when I retrieve a static resource, it won’t take much longer than normal (5ms). But it takes several seconds even. Is my expectation wrong?

dominicm11:04:11

That Thread/sleep probably locks up the thread pool.

mccraigmccraig11:04:56

hmm - that shouldn't affect static resources served by yada though, since it's the threadpool of a separate process

malcolmsparks11:04:11

Hmm. This is odd

malcolmsparks11:04:23

Your expectation is correct

dominicm11:04:40

Do you get comparable behaviour with something like (future (Thread/sleep 5000))?

dominicm11:04:59

I'm wondering if Thread/sleep is locking up the general aleph threadpool?

malcolmsparks11:04:16

But it's a separate proc

borkdude11:04:27

@dominicm The Thead/sleep is in a different process. From the perspective of Yada this is just IO

dominicm11:04:01

Oh, I see. I wasn't paying enough attention 😁

borkdude11:04:04

@malcolmsparks Do you want me to wrap this into an example project, so you can run it?

malcolmsparks11:04:37

What versions of yada/manifold/aleph? I'd like to replicate tonight

malcolmsparks11:04:41

(Terrible internet here)

thegeez13:04:33

@borkdude there's a max concurrent number of requests to the same domain in browsers, your README says you run the test from the same browser (tho different tabs). I think you hit a browser limitation and not a yada bug

thegeez13:04:33

Try the 20 request to /api/async with apache bench or something instead of from a browser

borkdude13:04:25

@thegeez ah, thanks, I’ll try

thegeez13:04:56

ab -n 20 -c 20 -v 10 -H 'Accept: application/json' ''

thegeez13:04:16

ab -n 20 -c 20 -v 999 -H 'Accept: text/plain' ''

borkdude13:04:40

Yup, that’s it. Thanks @thegeez !

borkdude13:04:27

@malcolmsparks So, mystery solved

dominicm13:04:49

😆 That's great

dominicm18:04:45

Apparently 1 tweet gets you on there 😛

danielcompton18:04:00

Nice detective work!