search

apache / openwhisk-runtime-java

Apache OpenWhisk Runtime Java supports Apache OpenWhisk functions written in Java and other JVM-hosted languages
https://openwhisk.apache.org/
Apache License 2.0
46 stars 63 forks source link

[Epic] Improvements to Java Runtime avoid com.sun.*, support MANIFEST main and other runtime image optimizations #12

Open kameshsampath opened 6 years ago

kameshsampath commented 6 years ago

The following are list of tasks that we need to work to improve the OW Java Action runtime:

  1. avoid usage of com.sun.* packages - this is used in https://github.com/apache/incubator-openwhisk-runtime-java/blob/master/core/javaAction/proxy/src/main/java/openwhisk/java/action/Proxy.java, instead we can use readily available pre-built httpservers e.g. using vert.x is one of the options for high performance

  2. Right now we rely on the --main parameter passed to run Java Aciton, instead we can make the Loader to infer it via MANIFEST.mf Main-class or add custom attribute for OW apps

  3. It would be great to have making OW Java Action use standard Java main method signature with just String[] args and we define custom Launcher that convert the args to JSON and delegate to OW Java Function Launcher, this way it will be easy for applications to be built and tested outside before testing in OW Edited by @csantanapr 3 is now a new issue: https://github.com/apache/incubator-openwhisk-runtime-java/issues/15

@csantanapr @ddragosd @gorkem - thoughts comments and feedback ??

rabbah commented 6 years ago

On 3, did you consider an openwhisk java FDK which provides a standard wrapper instead for local development?

csantanapr commented 6 years ago

What’s an FDK?

csantanapr commented 6 years ago

On 3 we are thinking on doing the same for Swift to handle the epilogue cc @jthomas User will just “import OpenWhisk” and write one of the signature main function with “main” name or given name and with argument type matching the wrapper code will know how to call it

csantanapr commented 6 years ago

Title says “performance” not all 3 items are about performance

rabbah commented 6 years ago

Function Development Kit - FDK is the new SDK, haven't you heard? :D

kameshsampath commented 6 years ago

@csantanapr - I mentioned the title as Improvements ;)

kameshsampath commented 6 years ago

@csantanapr and @rabbah - I just thought to file these things across about points I thought on Java Action before I forget - please feel free to let me know if you need them to split it up or wish me to do?

csantanapr commented 6 years ago

My bad I read performance, It must be my dislexia :-) or just brain fart I have being workin with someone to improve Java runtime with jvm optimization flags and openj9

rabbah commented 6 years ago

+1 for all three improvements: faster stratup is a win, and main in the manifest makes sense. My immediate concern was with your third point but think an FDK can facilitate local development and testing without changing the underlying model for functions.

@csantanapr should we link this to zenhub and track issues and epics accordingly?

csantanapr commented 6 years ago

Yes they are related and we should start using epics and child’s with zenhub

csantanapr commented 6 years ago

We should link all the runtime repos to main core repo, I will check if we still have the correct permissions now that we are under Apache Github org

csantanapr commented 6 years ago

One zenhub board for all repos

kameshsampath commented 6 years ago

My immediate concern was with your third point but think an FDK can facilitate local development and testing without changing the underlying model for functions.

can you please share more details not sure I got what you mean here

csantanapr commented 6 years ago

Keep the abstractions to developer so they can write functions with a stable api and it doesn’t matter if the run the function locally outside whisk or they run it in a whisk container

gorkem commented 6 years ago

We should add direct .java invocation to this epic too. I have it already implemented on the devtools repo. [1]. The only reason I did not PR it to here was the gson dependency. Since we are taking care of it with this one, I see no reason not to implement it.

[1] https://github.com/apache/incubator-openwhisk-devtools/tree/master/java-local

csantanapr commented 6 years ago

@gorkem I See no issue on adding .java also

@rabbah do you recall why this was not done originally for Java actions and only .jar?

Maybe the extra latency for compile step on /init too bad or takes longer than 1minute those would be the only two I see, put that’s a problem we have today with swift with single source file it’s convenient for dev/demo but for production is better to have a precompiled to the action

Maybe it’s time again to bring discussion of init actions that will help with compiling and saving the compiled output to the action stamping with runtime image and maybe source on the action this way it only compiled when the source changes or the runtime image changes.

rabbah commented 6 years ago

What’s the likelihood of writing a function is Java, with no extrnal libs? Supporting the use case is nice for parity and quick start but I’d suspect if you’re doing anything serious with functions and Java you’ll have libs and need a jar file.

csantanapr commented 6 years ago

Hum 🤔

  1. What about composer inline functions when Java is supported. ? Meaning like to transform output parameters into input parameters in sequences

  2. Maybe there is a OW provider/operator that included libraries and frameworks into a custom runtime IBM including Watson sdk, COS SDK, Cloudant sdk, http client library RedHat including spring cloud framework and adapters Regular user extending a Java runtime with own libraries

  3. Someone offering a UI web based editor useful for demo to edit a java file in web editor assuming that runtime has some useful libraries installed like Jax-rs related ones to handle web actions input.

rabbah commented 6 years ago

It’s nice to have - quick start, demo all good.

For composer it’s more nuanced. The library is js based today and it’s far more work getting java syntax embedded vs using a composer library entirely in Java. I suggest taking that off the table as a use case where 2 & 3 are more viable.

kameshsampath commented 6 years ago

@rabbah @csantanapr @gorkem

What’s the likelihood of writing a function is Java, with no extrnal libs? Supporting the use case is nice for parity and quick start but I’d suspect if you’re doing anything serious with functions and Java you’ll have libs and need a jar file.

This has been my thinking last couple of days in these lines

  1. I am not sure where are storing the jars today when we say wsk action create foo foo.jar --main foo - is it as a blob in couchdb ??

  2. As you mentioned that biggest stuff we need to resolve dependency resolution for Java - wondering we can deploy a Maven Repo Manager as part of the OW deployment, this could solve the above point as well,. Right now the biggest hurdle of Java Adoption is this as functions need to be quick

csantanapr commented 6 years ago

Hey @kameshsampath @gorkem @rabbah

I enable zenhub and pulled this repo up to core/main repo, tell me if you have issues loading zenhub (chrome plugin) here: https://github.com/apache/incubator-openwhisk/issues#boards?repos=104973620

I tried my best to split this issue in 3 Epics and copied over discussion to new issues

Let me know how this looks, and any adjustments you can to see and can't do because of write access. I hope you guys continue with these great contributions and can propose/nominate you for committer bits 🎉

kameshsampath commented 6 years ago

guys,

my first target for this EPIC would be to rebase the OpenWhisk Java runtime with https://hub.docker.com/r/fabric8/java-jboss-openjdk8-jdk/ as this will solve two issues #5 and we aligning to openjdk for all community bits.

@csantanapr can you please add this https://github.com/apache/incubator-openwhisk-runtime-java/issues/18 to the Epic ?