Fork me on GitHub

Question: can I access the interceptor chains of other routes from inside an interceptor (through some path in the context)?

Michael Stokley16:11:56

if i'm running a pedestal server in a separate thread (for testing purposes), how can i clean it up, or kill it? i've tried (.interrupt thread-with-running-server) but it doesn't seem to help

Michael Stokley16:11:41

we also tried putting the server in an atom and running (http/stop @server-atom) but since running the server blocks, it never gets swapped into the atom in the first place

Michael Stokley16:11:53

at least, this is what we think is happening

Michael Stokley16:11:08

should this just be handled by setting :http/join? to false?

Michael Stokley18:11:44

ok, figured this out. need to add a try catch in the function passed to the thread to allow it to be interrupt-able. then i can run whatever shutdown actions i need.


Join to false seems more robust to me

šŸ™ 1

Do pedestal (or some pedestal lib) do routing given the HTTP domain?


In ring/pedestal, the domain is the :host


So, let me tell you a story ... the other day, we had a network problem in our load balancers; this caused IO problems writing the response to the client (`io.pedestal.http.impl.servlet-interceptor/ring-response`); the exceptions thrown were caught by stylobate and logged. The exception occured inside io.pedestal.http.impl.servlet_interceptor/write-body. ā€¢ Problem was, other interceptors had attached large maps to the :request ; logging that produced 800KB of output per exception which caused a cascade of other problems ā€¢ When using io.pedestal.http/create-server you end up threading through io.pedestal.http.impl.servlet-interceptor/http-interceptor-service-fn where stylobate and ring-response interceptors are added ā€¢ This is in internal implementation, and things are private; very hard to override stylobate's behavior here without forcing access to private functions So, I'm changing our interceptors to, on leave/error, remove the added keys, but that's not totally foolproof. I really just want to tweak stylobate's logging to not include the context (or, perhaps, carefully include only selected keys from the context and request). I'm thinking the best solution might be to add our own own top-level error reporting interceptor and put a ring-response directly after; this will do the expected response writing work, and then the Pedestal-added ring-response will see that the response has already been committed (and the :body removed) and do nothing. TL;DR; if you are putting large maps into the context and they percolate back up out of your code, and an exception is thrown when writing the response stream to the client, then you will experience logging grief, and there isn't an easy way to override Pedestal's behavior here.

šŸ‘ 4

I'm trying a solution, an interceptor that sits early in the stack, and green-lists all the context and request keys (on enter) and uses select-keys on leave/error (obviously, also allowing :response).