Clojurians Log v2

START RequestId: e6768c98-0e4f-43fc-9160-d0a820bfe2cf Version: $LATEST
An error occurred during JSON parsing: java.lang.RuntimeException
java.lang.RuntimeException: An error occurred during JSON parsing
Caused by: java.io.UncheckedIOException: com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
 at [Source: (ByteArrayInputStream); line: 1, column: 1]
	at com.amazonaws.services.lambda.runtime.serialization.factories.JacksonFactory$InternalSerializer.fromJson(JacksonFactory.java:184)
Caused by: com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
 at [Source: (ByteArrayInputStream); line: 1, column: 1]
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:59)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1445)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1219)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1129)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.deser.std.StdDeserializer._parseString(StdDeserializer.java:609)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.deser.std.StringArrayDeserializer.handleNonArray(StringArrayDeserializer.java:304)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.deser.std.StringArrayDeserializer.deserialize(StringArrayDeserializer.java:132)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.deser.std.StringArrayDeserializer.deserialize(StringArrayDeserializer.java:21)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:1719)
	at com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1228)
	at com.amazonaws.services.lambda.runtime.serialization.factories.JacksonFactory$InternalSerializer.fromJson(JacksonFactory.java:182)

END RequestId: e6768c98-0e4f-43fc-9160-d0a820bfe2cf
REPORT RequestId: e6768c98-0e4f-43fc-9160-d0a820bfe2cf	Duration: 249.56 ms	Billed Duration: 250 ms	Memory Size: 512 MB	Max Memory Used: 206 MB	Init Duration: 8371.93 ms

I wonder a little if it is because it tries to parse everything that goes to stdout as json?

Maybe my handler needs some special signature

ok I needed to implement some handler like here https://docs.aws.amazon.com/lambda/latest/dg/java-handler.html at least that was a way

next time #holy-lambda 😅

We have a bunch of JVM lambdas, and all of them basically implement com.amazonaws.services.lambda.runtime.RequestStreamHandler interface https://gist.github.com/lukaszkorecki/4ddede30578bcdd00f043be861ba568f

@benjamin.schwerdtner you could use HL with Java as well, did you know that?

Memory consumption and cold start time is much lower for HL compared to AWS Official Runtime. Also you don’t have to use HL tasks if you don’t like and treat HL as just a library.

@karol.wojcik is the last part documented anywhere - I just had a quick look but couldn't find it

https://github.com/FieryCod/holy-lambda/blob/master/benchmarks/holy-lambda-vs-other-runtimes/README.md

Sorry, I wasn't clear - the bit about using HL as a library :-)

Here is the example that uses Docker images https://fierycod.github.io/holy-lambda/#/clojure-backend-tutorial

Here is the example with custom layer https://github.com/FieryCod/holy-lambda-on-java-17

Awesome, thanks!

Anyway, you can remove the bb tasks completely. What you need is compile the Clojure sources to uberjar and then build the custom layer as in the last example.

Fairly easy I would say and you can save some $ by this switch.

Also you can run full featured ring apps with HL on both native and Java/Clojure runtime via https://github.com/FieryCod/holy-lambda-ring-adapter.

It's already used in production, so I can recommend this one.

@karol.wojcik I totally should do this. I somehow thought using "just the java runtime" would be simpler but ended being a pain. But also my lambda only runs 1/day so right now I don't have a reason to switch 😄

Hope the lesson is learned :D