portkey 2018-04-27

making clj-http work would greatly increase usability of portkey 🙂

we need to hijack the part of the brain of @cgrand where the solution for this problem is boiling 🙂

this peculiar pot used to boil but has been put in the freezer

at times thinking that I need to learn to train my brain to be more efficient, or figure out how to calm the part that makes me do too large amount of context switch 🙂

cold brewing solution

@viesti I’m struggling digging up init errors from cloudwatch. Could you copy/paste them in the issue?

eek, my aws certification expired, wonder if I’m able to 🙂

hum, there’s a test, which might output even better the error

planned skills obsolescence

remembering that what ends up into Cloudwatch is the Attempting to call unbound fn: #’clj-http.core/request: java.lang.IllegalStateException

that’s what ends up in CloudWatch at request time

the actual error happens when the static init is performed

yes, as far as I rememer, that doesn’t end into Cloudwatch, but let’s see

so made a test, don’t find initialization logs in Cloudwatch

which is a bit odd

maybe the stub swallows it?

Nope. Can't now think of place to look from in AWS. But I remember making the clj-http test so that it reveals kryo errors: https://github.com/portkey-cloud/portkey/blob/e7492b086370bbb5f74032000cd649398d1bcc95/test/portkey/core_test.clj#L223

No, I remember reading them. Not in cloud watch then?

hmm, didn’t help

we found place that Cloudwatch logging doesn’t cover? 🙂

hmm, might actually be that only requires-time stdout/stderr is logged

but not process start-time output

butbut…

failure in the static initializer would result in handler not being assigned…

static init recreates vars and populates them, failure occurs during population of vars so some vars are left unassigned

still we get a handler

dealing with errors is error prone