Specify default memory parameters of java_application BASH script in the build

[abrutus]

I downloaded a sample app for the latest version of play
packaged it using debian:packageBin and then installed it in my VM with 512 megs of ram
but when I try to run it I get this

Error occurred during initialization of VM
Could not reserve enough space for object heap

While you can specify -mem to the script to fix this, it'd be nice if the default configuration for memory requirements was configurable.

[jsuereth]

Yeah, sort of. THe default is 1024M I believe. You can use the -mem option, or the -h option to see available options.

Here's the spot in code:

https://github.com/sbt/sbt-native-packager/blob/master/src/main/resources/com/typesafe/sbt/packager/archetypes/bash-template#L149

[abrutus]

👍 It works! app-name -m 128

Is there any way to set that number up through my build.sbt or something like that so I don't have to specify it every time I run the packaged version?

Thanks for your super fast response!

[jsuereth]

Not yet. I'll alter this to a feature request :)

[abrutus]

Okay thanks! If you outline the changes necessary I might be able to figure it out and send you a pull request

[muuki88]

Is it a good idea that the javaOptions in run will be appended to the etc-default template? The logic would be rather simple (append -J to every value which doesn't start with -D, right?)

Would this be to much magic? @jsuereth , @aparkinson

[jsuereth]

I'm pretty nervous about javaOptions in run making it into the packaging. Particularly because there's a divorce between the platform you develop on and the platform you deploy on (usually).

that's just me though. The idea of doing magic (as long as it's configurable) is great. As you've seen, most of the work in this 0.7 has been taking the initial magic of "auto java app" and adding in configuration that was missing. So, I'd be ok adding javaOptions in run.

[muuki88]

I never used this option so I have no idea how people use it and if they expect that their production system will look the same.

We may scope this to avoid confusion, like

javaOptions in (run, Linux)

[aparkinson]

I know in my use case our production javaOptions are very different from development and I wouldn't want them to get through

[muuki88]

Okay. Do you think scoping makes sense then?

[aparkinson]

Scoping seems reasonable and I have no objection to it

[huntc]

I'd like to re-visit this issue. As more microservice style applications are developed then having a default of -Xms1024m -Xmx1024m seems excessive. I recently observed a medium sized EC2 machine running out of space within only 3 services running.

Why not just lean on the default mx of Java which is 64m respectively. ms could still equal mx.

Developers need to think about the memory required for their apps. Unfortunately the current settings do little to provoke that thought in practice.

[muuki88]

@huntc the easiest way of doing the shell part would be to remove the -mem option. It adds a lot of possible errors in the bash script and doesn't add any convenience as the jvm figures out most of the stuff itself.

@jsuereth I really would like to remove this part as it only gets more tricky with each additional request.

[kardapoltsev]

+1 for removing -mem.