This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-18
Channels
- # aws (21)
- # babashka (32)
- # babashka-sci-dev (3)
- # beginners (17)
- # biff (1)
- # calva (8)
- # clj-kondo (1)
- # cljfx (8)
- # cljs-dev (3)
- # clojure (13)
- # clojure-belgium (1)
- # clojure-europe (16)
- # clojure-losangeles (2)
- # clojure-norway (6)
- # clojurescript (11)
- # conjure (1)
- # data-science (1)
- # fulcro (2)
- # gratitude (5)
- # helix (1)
- # joyride (3)
- # malli (14)
- # nbb (4)
- # off-topic (11)
- # other-languages (10)
- # polylith (4)
- # re-frame (2)
- # sci (3)
- # shadow-cljs (20)
- # spacemacs (3)
- # tools-deps (1)
- # vim (4)
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?
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
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
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.
@UJ1339K2B is the last part documented anywhere - I just had a quick look but couldn't find it
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
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.
@UJ1339K2B 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