Fork me on GitHub
#pedestal
<
2017-04-20
>
hagmonk18:04:50

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

hagmonk18:04:56

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

hagmonk18:04:46

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

ddeaguiar18:04:09

I can see this being done a number of ways

ddeaguiar18:04:27

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

mtnygard18:04:24

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

ddeaguiar18:04:02

@mtnygard true, pedestal.log has metrics support

hagmonk18:04:13

ooh, see I knew I was missing something

ddeaguiar18:04:33

actually that would probably be easiest, no?

ddeaguiar18:04:46

each :enter/:leave fn could emit a metric

mtnygard18:04:13

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.

ddeaguiar18:04:13

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

ddeaguiar18:04:00

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

hagmonk18:04:08

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

hagmonk18:04:34

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

hagmonk18:04:55

or investigate an IntoInterceptor record

ddeaguiar18:04:26

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

ddeaguiar18:04:58

I think it’s simpler to use a metrics wrapper

ddeaguiar18:04:35

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

hagmonk18:04:48

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

ddeaguiar18:04:07

great stuff to be found there!

hagmonk18:04:46

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

ddeaguiar18:04:40

Not familiar with Apache Ignite so I can’t comment

hagmonk18:04:16

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

hagmonk18:04:07

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"

hagmonk18:04:52

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

mtnygard18:04:06

I agree. 🙂

hagmonk18:04:54

I suspected you might 😉

hagmonk18:04:57

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