Dropwizard example?

[kennovak-zy]

Can this framework support Dropwizard? I have a REST server using dropwizard, JAX-RS, and hibernate and would like to port to Lambda. If there are any examples of how to do this, please let me know. Thanks

[sapessi]

Hey @kennovak-zy - I suspect it is possible. Ultimately Dropwizard can use Jersey behind the scenes. I'll have a go at this as soon as possible and let you know.

[spullara]

I'm working on a custom runtime for running AWS Lambdas with Java 9+. I'd love to get Dropwizard working with this as well. If anyone has a theory on how to get it to work I'd love to hear it. Do you think changes to Dropwizard would be required?

[aharnly-amplify]

@kennovak-zy , @sapessi, or @spullara did you ever get any traction on running Dropwizard applications with minimal changes under aws-serverless-java-container (or another helper)?

[sapessi]

I haven't had a chance to look into it yet. Working on the 1.3.2 bug-fix release. I'll try to look into it for the 1.4 release. Could you add a +1 to the original comment so that I can track interest in the framework support?

[sapessi]

Hi @kennovak-zy, @spullara, @aharnly-amplify. I've started working on Dropwizard support and have a basic version working in the dropwizard branch of this repo. I've also added a hello world example that you can simply mvn package and run in AWS Lambda. Lots of work still to be done in terms of understanding the internals of dropwizard and improving performance. I'm no expert so I'd like to ask for your help - can you help me test with your applications? I'm looking for something more complex/taxing than hello world.

1. Git clone/download the dropwizard branch to your local environment
2. Run mvn install from the root of the repository to make all the packages available in your local maven repo
3. Add the dropwizard version of this package as a dependency (1.4-SNAPSHOT)
4. Create a LambdaStreamHandler and pass your application and configuration file to the handler just like I do in the sample. The config file name should be the relative path of the config file starting from the resources folder.

[aharnly-amplify]

Thanks @sapessi ! We will test drive this with a one or two of our production Dropwizard applications over the next few weeks – happy to try and learn with you guys. cc @bcerrato-amplify.

[Kumaresan89]

Hi sapessi, As I followed your steps in Dropwizard, but I am getting the below error after mvn install,

Running com.amazonaws.serverless.proxy.AwsProxyExceptionHandlerTest [main] ERROR com.amazonaws.serverless.proxy.AwsProxyExceptionHandler - Called exception handler for: com.amazonaws.serverless.exceptions.InvalidResponseObjectException: Invalid response error at com.amazonaws.serverless.proxy.AwsProxyExceptionHandlerTest.typedHandle_InvalidResponseObjectException_jsonContentTypeHeader(AwsProxyExceptionHandlerTest.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) com.amazonaws.serverless.exceptions.InvalidResponseObjectException: Invalid response error at com.amazonaws.serverless.proxy.AwsProxyExceptionHandlerTest.typedHandle_InvalidResponseObjectException_jsonContentTypeHeader(AwsProxyExceptionHandlerTest.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

[davidmc24]

For anyone who may be interested, I've managed to get a slight variant of this working for a Dropwizard 0.7.1 app that I needed to deploy to AWS.

https://git.nexus.commercehub.com/snippets/291

[sapessi]

Nice! thanks @davidmc24 - I'll go through it next week. Haven't decided yet whether I want to create a completely separate package for Dropwizard or just work on an example that shows how to use the existing Jersey support.

[aharnly-amplify]

I'll summarize our findings from our POC. For context, we have a sizable suite of microservices that currently run in ec2 (most with RDS), which we are considering migrating to docker and/or lambda. We chose a relatively simple Dropwizard service to evaluate the effort and results of converting to Docker, Lambda via aws-serverless-java-container, and Lambda with a refactor.

1. We made a few small changes to support Dropwizard 1.3.9 (rather than 2.0.0-rc4). Those are here:

https://github.com/awslabs/aws-serverless-java-container/compare/dropwizard...amplify-education:dropwizard

2. The cold start times were, to no great surprise, very long – around 18 seconds.

3. Again not a surprise, the database pooling configured for our dropwizard deployment wouldn't work very well in a lambda deployment.

In short, as we suspected heading in, we concluded that we'd do better to do one of:

a) Put substantial work into a version of the serverless container that essentially neuters Dropwizard, exposing the resources more directly to lambda. This would take real work.

b) Refactor our applications to remove Dropwizard and optimize for a lambda environment.

c) just run in Docker

[sapessi]

Thanks for the summary and code sample @aharnly-amplify. I'll try to dig into this. Do you have a public sample of the slow application I can test with?

[jplock]

Any interest in restarting this effort? We (the Dropwizard maintainers) recently released v4.0.1 that we could try and add as a sample?

[msailes]

Please feel free!

[deki]

@jplock We haven't seen requests for it lately but open to review and merge related pull requests.