Fork me on GitHub

Anyone, Does aleph have any issues with :multi in malli schema? After schema validation the request body Inputstream is empty.


I don't know about aleph, but an InputStream can only be read once.


Thanks @U07FCNURX that helps but my query is that where the big lies either at malli’s end or aleph’s end


@U07FCNURX ' response gave you all the info you need if you actually take the time to understand it Surely Malli validation reads the InputStream once, that prevents further reads Whose bug is it? It doesn't matter, it's just how InputStream works, if you don't like it, wrap it in a custom type that is idempotent

Matthew Davidson (kingmob)08:05:12

This is not strictly correct. Many InputStreams support mark and reset, to enable rereading a stream, though Aleph’s underlying library byte-streams doesn’t promise to return a markable stream in general.


Thanks for a detailed input guys that helps a lot @U45T93RA6 @U10EC98F5 :spock-hand:

Matthew Davidson (kingmob)08:05:26

@U030SSZRHGA Generally, if you don’t want to deal with an InputStream in your Aleph handler, you would use something like clj-commons.byte-streams/to-string or clj-commons.byte-streams/to-byte-array first. Check out the examples/ subdirectory in Aleph, or see


Awesome thanks @U10EC98F5 let me check with the suggestion you mentioned. Thanks man :spock-hand:

👍 1

@U10EC98F5 the suggestion is for http-client but I am working on the server part with the ring-handler for routes. Your example seems to solve my web-app issue but not the server issue

Matthew Davidson (kingmob)07:05:53

@U030SSZRHGA I’m a little confused as to your situation. byte-streams works on the server-side, too. The :body of the req is an InputStream (usually a ByteArrayInputStream). E.g. here’s a ring handler to upper-case the body:

(defn body-upper-case-handler
  {:status 200
   :body   (-> req :body bs/to-string str/upper-case)})
I don’t know how Malli works, but if something is consuming the stream and not passing the contents along, you should extract it first and validate second.


Let me check extracting the values @U10EC98F5

Al Z. Heymer14:04:52

When I am the Code running in a future/`future-call`, is there a possibility to react to being cancelled, e.g. by future-cancel?



👎 1

Hi! We have a code reloading process for our backend server that was recently ported from leiningen to tools-deps. We are using ns-tracker and a loop that checks for changes every 500 ms. Reload code itself looks like this:

($/info "Reloading namespace:" ns-sym)
(require ns-sym :reload)
($/info "Done reloading namespace:" ns-sym)
Many namespaces take a long time from the first log statement to the last (couple of seconds or more). Before transitioning to tools-deps, there was no noticeable delay. I know this isn’t a particularly solid reproducible report, and this probably isn’t the tool’s fault. I’m just posting this here in case anyone using tools-deps ran into this at some point and knows the reason for it.

Alex Miller (Clojure team)17:04:48

How is tools.deps involved?


Not much really. Only difference I could think of is some slight difference in dependency resolution, which i’m checking in depth now, or how the process is launched. But hardly any reason to think that either, started with lein run before, starts with clojure -M:run now


where the :run alias points to the same main that was run by lein before

Alex Miller (Clojure team)17:04:03

Well, not sure I see how that would be any different

Alex Miller (Clojure team)17:04:31

When it's slow, try taking some thread dumps with ctrl-\


Do you compare it on the same environment and for example not jar file vs REPL in editor?


Also the same Java version


@U064X3EF3 Thanks! I’m not good at interpreting those dumps, so I’ll show it to one of my colleagues tomorrow


@U0WL6FA77 Yes same environment, starting from source code, main fn. Could be that our java version went from 15 to 17 somewhere in this process, that’s also a good point to check out


Problem turned out (as always) to be something unrelated to the first hypothesis. It was indeed caused by switching to tools-deps, but not the way I thought. The old version had AOT, the new version did not. Old version was fast because of that… Thank you for taking the time to respond!


I have a deftype declared as follows:

(deftype DTSConnectionPool
  [^:volatile-mutable availableConnections
   ^:volatile-mutable busyConnections
   ;; ... other non-mutable fields

  (initialize [this]
    (locking this
      (set! availableConnections [])
      (set! busyConnections [])))
  ;; ... more methods
However, I am getting an error that says "Cannot assign to non-mutable: availableConnections" on the line that attempts to set availableConnections. What's wrong with the declaration that's causing the compiler to not recognize the attribute as mutable?


That did it. I'm still not sure why, as direct naming of the non-mutable attributes seems to work in other contexts, but thanks for that.


Oh the (.-availableConnections this) thing? Interesting, I looked a little more at the usages and it seemed wrong, guess I should have left it up.