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

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:

@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 https://aleph.io/aleph/literate.html#aleph.examples.http.

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

@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

@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
  [req]
  {:status 200
   :body   (-> req :body bs/to-string str/upper-case)})

Let me check extracting the values @U10EC98F5

You can wrap the code in try-catch and handle https://docs.oracle.com/javase/7/docs/api/java/lang/InterruptedException.html

(Thread/interrupted)

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

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

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

See what it's doing

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!

:thumbsup:

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.