lifadev / archive_aws-lambda-go-net Goto Github PK

All the examples start the http server from inside init() func instead of the usually used main() func. Is there a reason behind this? And if yes, could this be documented?

Hello, forgive me if my question's answer is obvious but it seems I am missing something.

I saw that the listener's Accept() method is protected by a channel (inc). This implies that only one request can be handled each time, hence one Lambda invocation right?
Why do you have this limitation? Can't we have the net package declare new variables for each request instead of resetting the global vars?

Thanks

Hi, can you cut a release so I don't have to deploy master?

Thanks!

I get this error when I invoke the function ?

It happens in my test with the basic example code:
https://github.com/eawsy/aws-lambda-go-net/tree/master/_example/basic

If I invoke the function I get the error. It does not matter if I invoke from the commandline or using the API Gateway. Both give the same error.

Below the log of one test request, from both the API Gateway and AWS Lambda.

Any ideas what could go wrong ?

Execution log for request test-request
Fri Aug 04 18:55:13 UTC 2017 : Starting execution for request: test-invoke-request
Fri Aug 04 18:55:13 UTC 2017 : HTTP Method: GET, Resource Path: /
Fri Aug 04 18:55:13 UTC 2017 : Method request path: {}
Fri Aug 04 18:55:13 UTC 2017 : Method request query string: {}
Fri Aug 04 18:55:13 UTC 2017 : Method request headers: {}
Fri Aug 04 18:55:13 UTC 2017 : Method request body before transformations:
Fri Aug 04 18:55:13 UTC 2017 : Endpoint request URI: https://lambda.eu-central-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:eu-central-1:061029286405:function:golang-preview/invocations
Fri Aug 04 18:55:13 UTC 2017 : Endpoint request headers: {x-amzn-lambda-integration-tag=test-request, Authorization=*********************************************************************************************************************************************************************************************************************************************************************************************************dbd72d, X-Amz-Date=20170804T185513Z, x-amzn-apigateway-api-id=c49ynl0n82, X-Amz-Source-Arn=arn:aws:execute-api:eu-central-1:061029286405:c49ynl0n82/null/GET/, Accept=application/json, User-Agent=AmazonAPIGateway_c49ynl0n82, X-Amz-Security-Token=[TRUNCATED]
Fri Aug 04 18:55:13 UTC 2017 : Endpoint request body after transformations:
Fri Aug 04 18:55:13 UTC 2017 : Sending request to https://lambda.eu-central-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:eu-central-1:061029286405:function:golang-preview/invocations
Fri Aug 04 18:55:13 UTC 2017 : Received response. Integration latency: 112 ms
Fri Aug 04 18:55:13 UTC 2017 : Endpoint response body before transformations: {"errorMessage":"RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346 Process exited before completing request"}
Fri Aug 04 18:55:13 UTC 2017 : Endpoint response headers: {x-amzn-Remapped-Content-Length=0, x-amzn-RequestId=72a77d10-7946-11e7-b375-efd5be3a9346, Connection=keep-alive, Content-Length=107, X-Amz-Function-Error=Unhandled, Date=Fri, 04 Aug 2017 18:55:13 GMT, X-Amzn-Trace-Id=root=1-5984c311-5177729f4c5c6d7167442086;sampled=0, Content-Type=application/json}
Fri Aug 04 18:55:13 UTC 2017 : Method response body after transformations: {"errorMessage":"RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346 Process exited before completing request"}
Fri Aug 04 18:55:13 UTC 2017 : Method response headers: {X-Amzn-Trace-Id=sampled=0;root=1-5984c311-5177729f4c5c6d7167442086, Content-Type=application/json}
Fri Aug 04 18:55:13 UTC 2017 : Successfully completed execution
Fri Aug 04 18:55:13 UTC 2017 : Method completed with status: 200

AWS Lambda:

START RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346 Version: $LATEST
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x7f0f111bccc0]
goroutine 17 [running, locked to thread]:
github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy.(*Server).Handle(0xc420114460, 0xc42008edc0, 0x2, 0x8, 0xc4200ca200, 0x0, 0xc4200e7958, 0x7f0f137c6d0c)
/go/src/github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy/server.go:115 +0xef0
github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy.(*Server).Handle-fm(0xc42008edc0, 0x2, 0x8, 0xc4200ca200, 0x0, 0x0, 0x0)
/go/src/bitbucket.org/greulen/lambda-hello/main.go:15 +0x54
reflect.Value.call(0x7f0f1146aac0, 0x7f0f11604440, 0x193, 0x7f0f13887078, 0x4, 0xc4200e7e10, 0x2, 0x2, 0x7f0f13ab99c0, 0x7f0f13ae1368, ...)
/usr/local/go/src/reflect/value.go:434 +0x921
reflect.Value.Call(0x7f0f1146aac0, 0x7f0f11604440, 0x193, 0xc4200e7e10, 0x2, 0x2, 0xc4200ca278, 0x193, 0x7f0f137ddb48)
/usr/local/go/src/reflect/value.go:302 +0xa6
main.handle(0x7f0f13d91cd4, 0x7f0f17607254, 0xf15c04, 0xc4200e7eb0, 0xc4200e7eb8, 0x0)
/build/src/runtime.go:140 +0x4e1
main._cgoexpwrap_dd780bcacc70_handle(0x7f0f13d91cd4, 0x7f0f17607254, 0xf15c04, 0x0, 0x0, 0x0)
_/build/src/_obj/_cgo_gotypes.go:127 +0x9a
END RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346
REPORT RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346 Duration: 39.40 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 25 MB
RequestId: 72a77d10-7946-11e7-b375-efd5be3a9346 Process exited before completing request

https://s.natalian.org/2017-07-04/handler.go fails to detect a posted image is a JPEG, instead it see it as application/octet-stream.

Whilst in local testing, https://s.natalian.org/2017-07-04/main.go, it works fine.

My test script is something like:

curl -X POST http://localhost:8000/upload \
        -F "[email protected]" \
        -H "Content-Type: multipart/form-data"

Sidenote: Wish I knew why it takes so long to iterate.

It points to here:

https://godoc.org/github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net

but might be less confusing to point to here:

https://godoc.org/github.com/eawsy/aws-lambda-go-net

Hi, I may be missing something here so correct me if I'm wrong. What's the reason behind proxying requests and responses over an additional TCP socket when both apigatewayproxy.Handle and a developer's http.Handler are operating in the same process?

Can't we just build an http.ResponseWriter, hand it off to a registered http.Handler and transform it into an *apigatewayproxy.Response? Even better, couldn't apigatewayproxy.Response implement http.ResponseWriter? There wouldn't be any additional networking, in either case.

Looking forward to your clarification! 😄

I used the latest example code and I'm getting this crash:


23:56:13
START RequestId: d10de6a0-ffa3-11e6-9a01-0108fefdc89d Version: $LATEST

23:56:13
panic: runtime error: invalid memory address or nil pointer dereference

23:56:13
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x7f01b6396db3]

23:56:13
goroutine 17 [running, locked to thread]:

23:56:13
github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy.(*Server).Handle(0xc420014ee0, 0xc420014f30, 0x2, 0x8, 0xc420072280, 0x0, 0xc4200c7940, 0x7f01bcad0e6c)

23:56:13
/go/src/github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy/server.go:87 +0x1c3

23:56:13
github.com/eawsy/aws-lambda-go-net/service/lambda/runtime/net/apigatewayproxy.(*Server).Handle-fm(0xc420014f30, 0x2, 0x8, 0xc420072280, 0x0, 0x0, 0x0)

23:56:13
/tmp/handler.go:17 +0x54

23:56:13
reflect.Value.call(0x7f01b66445a0, 0x7f01b67dc440, 0x193, 0x7f01bcb90db8, 0x4, 0xc4200c7de0, 0x2, 0x2, 0xc4200bb680, 0x7f01bce59850, ...)

23:56:13
/usr/local/go/src/reflect/value.go:434 +0x921

23:56:13
reflect.Value.Call(0x7f01b66445a0, 0x7f01b67dc440, 0x193, 0xc4200c7de0, 0x2, 0x2, 0x0, 0x193, 0x13)

23:56:13
/usr/local/go/src/reflect/value.go:302 +0xa6

23:56:13
main.handle(0x7f01be09c054, 0x2161694, 0x20c5a94, 0xc400000008)

23:56:13
/tmp/src/runtime.go:127 +0x5ff

23:56:13
main._cgoexpwrap_7d7ac51857d8_handle(0x7f01be09c054, 0x2161694, 0x20c5a94, 0x0)

23:56:13
_/tmp/src/_obj/_cgo_gotypes.go:125 +0x74

23:56:13
END RequestId: d10de6a0-ffa3-11e6-9a01-0108fefdc89d

23:56:13
REPORT RequestId: d10de6a0-ffa3-11e6-9a01-0108fefdc89d	Duration: 30.44 ms	Billed Duration: 100 ms Memory Size: 1024 MB	Max Memory Used: 17 MB

23:56:13
RequestId: d10de6a0-ffa3-11e6-9a01-0108fefdc89d Process exited before completing request

Hi,

Am I correct that aws-lambda-go-net is not passing on a redirect properly to the client?

I think it gets stuck in this component and doing a redirect locally ...

Cheers
Gerd