Found a problem with sieparri and reitit, it's including slf4j-nop as a dep, which is forcing an implementation on the consumers of the library. Raised an issue on github.
Caused by: java.lang.UnsupportedClassVersionError: reitit/Trie has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
first time seeing this after attempt to update to reitit 0.5
@dharrigan oh my. for some reason, the sieppari lein config thinks that all :dev
dependencies should be packaged too.
fixed that.
fantastic news! thank you! 🙂
@fmnoise will fix that today, jsonista deployed with java11. thanks for reporting.
[metosin/reitit "0.5.1"]
should have fixed both problems.
hey @ikitommi this is just a shoutout of huge thanks for pohjavirta
i'm trying my hands at doing something netty from the ground up and the ways you squeeze out so much performance, it's a great lesson
currently at Requests/sec: 187940.22
(though i'm doing nothing dynamic like your json encoding example so i've got ways to go)
thanks @vale! perf tuning is kinda fun, there is usually room to improve, a lot. Pull back if you find anything silly in pohjavirta.
i still don't understand how you can get down to like 100us... the best i can reach is like 500us and then i'm lucky
what are good places to look for improvements at such timescales?
Just tested the front end fix to push-state!
in 0.5.1
. Thanks for this! I circled around why I couldnt call push-state!
in the on-navigate
for a good several hours. Saved me having to come back to this and dig into the source…I should do this anyways though.
Is sieppari only meant to be used for web interceptors? I see that some keys are hardcoded to be :request
which sounds web-related. (Context: I want to add interceptor-like support for a state management lib)
@orestis It was designed with that in mind but there's an alternate function that works more generally. Use sieppari.core/execute-context
which will operate fully on the context, doesn't use request and response, and doesn't require a handler at the end of the initial queue.
Ah super - thanks for clarifying!