so I'm finding lots of use cases for interceptor chains in some data processing code I'm writing

I'd like to re-use io.pedestal.interceptor for this if possible, but one of the primary things I would like is a way to instrument each :enter and :leave function so I can compute stats about how long the chain takes and what is slowing it down

so far I don't see an obvious hook in the source where I can wrap each interceptor ... could I be missing something?

I can see this being done a number of ways

when you construct an interceptor, the :enter and :leave impls are just functions. wrap them with a higher-order fn that keeps track of timing. But it might be better to implement a stateful interceptor

You can create a record that implements the IntoInterceptor protocol https://github.com/pedestal/pedestal/blob/master/interceptor/src/io/pedestal/interceptor.clj#L23

@hagmonk I'll also put in a plug for the pedestal.log module as a way to convey the metrics out of the process

@mtnygard true, pedestal.log has metrics support

ooh, see I knew I was missing something

actually that would probably be easiest, no?

each :enter/:leave fn could emit a metric

well, I don't want to get you too excited... the interceptor chain provider doesn't track metrics. that is still up to your interceptors.

yes, but you’re free to emit metrics using pedestal.log from your lifecycle implementations

given that, I’d use a higher-order fn which does that and wraps the :enter/:leave impls

it seems to use dropwizard which is perfect, the wrapper looks nicer than metrics-clojure anyway

so I could create an interceptor chain, then map a wrapper fn that handles metrics over that

or investigate an IntoInterceptor record

hrm, I’ll redact my IntoInterceptor record recommendation. At least for now

I think it’s simpler to use a metrics wrapper

Of course I’m designing this off the top of my head. The key insight is to use pedestal.log’s metric support

I think it's simpler too, but I'm learning a lot by reading the pedestal source

great stuff to be found there!

I'm executing this chain on top of an Apache Ignite cluster so I'm pondering if I can capitalize on that somehow

Not familiar with Apache Ignite so I can’t comment

ideas will come to me as I implement, more just thinking out loud 😉

I've been musing on this idea for general Clojure functions, but maybe interceptors are a better context. That idea was attaching metadata to functions that simply says "time how long this takes", or "attach this Failsafe policy", or "rename the thread of execution inside this function"

seems like I could build that on top of interceptors way easier than trying to figure out how to do meta magic on top of naked clojure functions

I agree. 🙂

I suspected you might 😉

oh, the interceptor queue is an instance of the furtive clojure.lang.PersistentQueue. Cool.