This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-07
Channels
- # beginners (142)
- # boot (18)
- # cider (39)
- # cljs-dev (2)
- # cljsrn (11)
- # clojars (8)
- # clojure (51)
- # clojure-brasil (3)
- # clojure-italy (22)
- # clojure-losangeles (2)
- # clojure-nl (20)
- # clojure-nlp (2)
- # clojure-russia (4)
- # clojure-serbia (2)
- # clojure-spec (90)
- # clojure-uk (147)
- # clojurescript (116)
- # data-science (10)
- # datomic (189)
- # devcards (31)
- # duct (6)
- # emacs (12)
- # fulcro (16)
- # graphql (36)
- # juxt (1)
- # off-topic (5)
- # om (11)
- # overtone (2)
- # pedestal (4)
- # perun (1)
- # portkey (17)
- # reagent (6)
- # reitit (3)
- # shadow-cljs (57)
- # spacemacs (45)
- # specter (8)
- # tools-deps (46)
I have been chasing concurrency gremlins in a project, and after trace logging I see resolvers returning values that never seem to get delivered to the promise returned from execute-parsed-query-async, I have a patched version of com.walmartlabs.lacinia.resolve/resolve-promise that seems to fix it, should I submit a pr? I don't have a small reproducible test case for it
Looks good, though if you look at the implementation of Promise, I'm surprised it makes a difference.
I am not sure what you mean by Promise
? If you mean clojure.core/promise
the issue is using two promises without coordination between them. if one thread runs on-deliver! up to line 156, then in the middle there another thread runs all of deliver! up to line 174, then both threads miss each other
that would be super. I haven't figured out what I want to do until this fix is upstreamed, I've got plenty of other issues to deal with, and we have direct linking turned on for deployments, so money patching is tricky
I'll want to see if there's performance impact from this change but it probably needs to go in either way, for correctness.
Are there any known/common issues with lacinia and concurrency? & if so, is there documentation anywhere re dealing with it? When several requests are made in rapid succession, I end up with lacinia/execute
throwing some pretty weird errors, eg
{:message "Exception applying arguments to field `chart_data': For argument `chart_params', for input string: \".2201071717E4.2201071717E4\"", :query-path [], :locations [{:line 1, :column 0}], :field :chart_data, :argument :chart_params, :value "2017-10-01", :type-name :Date}
That looks like several of those date values are getting interleaved.
I can solve it without much trouble by putting lacinia/execute
behind a global queue, and executing queries one at a time, but of course there are possible perf costs there. If there are existing patterns around lacinia & concurrency, I'd love to get a pointer to them.
And of course it could turn out that this is unrelated to lacinia -- but at first sniff that seems the most likely.
Thanks!Just that if you compare ".2201071717E4.2201071717E4"
to "2017-10-01"
it looks suspiciously like the former is being built from multiple, interleaved copies of the latter, along with some other bit of data. Could be totally wrong; I'm just hard-put to see where else that bizarre string could be coming from.
oh, you are likely using SimpleDateFormat to parse the date, and that class isn't thread safe
oh man, I've spent several hours debugging exactly that problem, probably three times in my career.
Those lacinia errors are still a bit opaque to me -- just out of being new to them -- so it probably would have taken me a painfully long time to realize that it was about the val being passed to the date parser.
I see this in the docs -
By convention, the built-in scalar types are identified as symbols, such as {:type String}. Other types (objects, interfaces, enums, and unions) are identified as keywords, {:type (list :character)}. It actually makes no difference; internally everything is converted to keywords in the compiled schema.
Does this mean that {:type list(:Int)}
is viable in a schema.edn
file? Just want to confirm that I am understanding this correctly.{:type (list Int)}
and {:type (list :Int)}
are exactly the same, just a matter of personal preference.
Iām trying to use a tool to generate schema docs from an introspection query and itās giving me this error back:
I'll have to research that; our directives support is not very good and it's quite likely we're missing something there.