Comments (25)
I opened a PR for the docs here: docker-library/docs#709
from docker-jetty.
@lfoppiano You would pass -Xmx
to the container via the JAVA_OPTIONS
environment variable:
$ docker run -d -p 80:8080 -p 443:8443 -e JAVA_OPTIONS='-Xmx1g' jetty
If you have a derived image that is FROM jetty
, then you can use the ENV
directive in your Dockerfile
instead.
@gregw Would you still be willing to create a PR for the jetty
image documentation so this information is easier to find?
from docker-jetty.
@step76 Right now, the only way to do this is to replicate the default command with your additional flags.
Here's what it looks like in a Dockerfile:
FROM jetty:9.3
CMD ["java","-Djava.io.tmpdir=/tmp/jetty","-Xmx1g","-jar","/usr/local/jetty/start.jar"]
Here's what it looks like on the command line:
$ docker run -d -p 80:8080 -p 443:8443 jetty java -Djava.io.tmpdir=/tmp/jetty -Xmx1g /usr/local/share/jetty/start.jar
from docker-jetty.
@gregw This seems to be a drawback of moving away from jetty.sh
. Do you guys have any plans to introduce a jetty
shell script that has less init
cruft than jetty.sh
but still allows for setting things like this via JAVA_OPTIONS
?
from docker-jetty.
We could look at that, but it would be very difficult to come up with a one size fits all script.
Isn't the solution here to modify the docker-entrypoint.sh script to inject $JAVA_OPTIONS into the default command line? Perhaps we change the default CMD to just be the arguments to java, as the entry point already handles that and injects a java command. That way if somebody explicitly specified a java command they could set whatever options they like... if they went with the default then they would be able to use JAVA_OPTIONS to control the the JVM.
I'd much rather just have a single script rather than a script that invokes another script and then jetty.
from docker-jetty.
@gregw If we put that into the entrypoint, then the CMD
stops being self-documenting. Right now, the entrypoint only injects the default java
command if a non-executable argument is passed as the first argument to the docker run
command.
I'd rather not have the default CMD
just be the arguments to java
, since the user would still have to remember to add -jar /usr/local/share/jetty/start.jar
in that case if they wanted to modify anything else, since the filename after -jar
signals the end of JVM arguments and the start of main
arguments.
I suppose that modifying the entrypoint to know about JAVA_OPTIONS
is the least bad option. Another options could be to look for arguments starting with -X
and -D
in "$@"
, but there's also -javaagent
and possibly other things that need to go before -jar
.
Incidentally, I noticed while investigating this that the argument order in the entrypoint is weird. The -Dio.tmpdir
is between -jar
and its argument. It's been that way since #17. I wonder if that functionality even works...
from docker-jetty.
@md5 quick explanation of the ordering and then I'll consider other points in another comment. The start.jar mechanism can look at the modules and determine that jvm args are needed (Eg if ALPN was enabled), so in that case start.jar will fork another JVM instance. Putting the -D after the -jar means that the JVM arg is for the JVM that will run jetty and not for the instance that will run start.jar. So that's how it works.
However, it should be safe to put it before the -jar as such values should be copied over to the target JVM if one is needed. Putting it after the -jar means that a second JVM is always needed. So let's open another issue to consider if that is the ordering we want: #38
from docker-jetty.
So how about making the CMD:
CMD ["java","\$JAVA_OPTIONS,"-Djava.io.tmpdir=/tmp/jetty","-jar","/usr/local/jetty/start.jar"]
Note the $, so the entry point script can look for unexpanded $JAVA_OPTIONS and do the expansion. This would allows users to over-ride the command and decide to either use that expansion or instead directly specify all their args
from docker-jetty.
@md5 Ah regarding the ordering issue - no that does indeed look broken! I'll comment on #38
from docker-jetty.
@gregw I'm not too keen on detecting the unexpanded $JAVA_OPTIONS
... I started to write up something that looks if "$1"
is java
and $JAVA_OPTIONS
is set to a non-empty value, but what I was writing would fall down if someone set both $JAVA_OPTIONS
and a custom command starting with java
.
@tianon Do you have any thoughts on this? To summarize:
- Our current
CMD
isCMD ["java","-Djava.io.tmpdir=/tmp/jetty","-jar","/usr/local/jetty/start.jar"]
- We want users to be able to specify additional options to the JVM, which will need to go before the
-jar
argument, as well as passing additional arguments to Jetty itself after the finalstart.jar
argument
Other Java daemons like Elasticsearch have their own shell script that knows to look for $JAVA_OPTS
or something similar, which is then generally wrapped with a Docker-specific entrypoint in the official images (as you're well aware).
from docker-jetty.
@tianon Also, as you may remember, this image originally called jetty.sh
, which does know to look for Java options in an environment variable, but we moved away from it because it has too much init
-specific logic in it.
from docker-jetty.
@md5 Currently we have CMD and entry point:
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["java","-Djava.io.tmpdir=/tmp/jetty","-jar","/usr/local/jetty/start.jar"]
Which has the benefit of making the default command line visible in the docker file.
However, let's say the distribution had a suitable jetty-start.sh
script, then the docker file would end up being just:
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["$JETTY_BASE/bin/jetty-start.sh"]
and we'd lose visibility of the default command line anyway.
So can we not just have an empty default CMD and move all the default command line into docker-entrypoint.sh:
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD []
Users could then: set just JAVA_OPTIONS
, which would be used by the default command line in docker-entrypoint.sh
; OR set their own CMD
, which would be used directly by docker-entrypoint.sh
as the command line if executable, or have java
appended if not; OR set their own CMD
and JAVA_OPTIONS
, which would be used directly by docker-entrypoint.sh
as the command line if executable, or have java $JAVA_OPTIONS
appended if not.
from docker-jetty.
@gregw I think losing visibility of what's inside the jetty-start.sh
script would be fine, assuming that script was the standard way to start Jetty and the ways to affect its behavior were well documented (as it is in the case of elasticsearch
, neo4j
, etc).
Since that's not currently the case and it doesn't seem to be on your roadmap, then I think doing something in the entrypoint makes sense. I'm not sure whether or not having a default CMD
that mimics what happens in the entrypoint is a good idea or not. Since @tianon has written many of the official image entrypoints, I'd like to get his opinion as well.
from docker-jetty.
@md5 as @tianon is currently silent, I've had a look at some of the docker images he works on:
haproxy has a Dockerfile that does include visible CMD:
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["haproxy", "-f", "/usr/local/etc/haproxy/haproxy.cfg"]
But interesting the docker-entrypoint.sh script inspects and modifies that CMD. If it is left as haproxy
then it will always replace the command with haproxy-systemd-wrapper
and insert a -p argument. Importantly, it does not give the user the option of specifying their own command with a -p and avoiding the argument injection!
He's not committed to many other directly relevant projects, but looking further afield I can see other examples of entry points that modify the CMD from the docker file:
So if we had an entry point that checked if $1 was java and if so it added $JAVA_OPTIONS, then we would not be an island.
I think I'll prepare a PR for this.
from docker-jetty.
from docker-jetty.
@md5 I created the PR. However I could not find a script generate-stackbrew-library.sh
, but I did run the test/run.sh script
from docker-jetty.
It's in this repo: https://github.com/appropriate/docker-jetty/blob/master/generate-stackbrew-library.sh
from docker-jetty.
Oh man, my inbox is such a train wreck; sorry I missed this entire conversation! Glad it ended up in a solid place in spite of me! 👍
from docker-jetty.
@md5 Argh! I missed the alpine subdir! Plus my manually updated stackbrew listed a newer tag for the alpine version!
Standby....
from docker-jetty.
@md5 Here is another PR fixing alpine and also removing the now unused ENV variables
from docker-jetty.
Reopening as we need to update documentation.
from docker-jetty.
Hi, It's not that easy to follow the thread, at the end what would be the implemented solution?
Which version should I use?
Thanks
Luca
from docker-jetty.
@md5 thanks.
To check that the parameters are correctly set, I need to connect to the container
docker exec -i -t 231b05ab1cbd /bin/bash
and check the environment variable:
root@231b05ab1cbd:/var/lib/jetty# echo $JAVA_OPTS
-Xmx4g
from docker-jetty.
There's not really a straightforward way to do that, but here are some options:
- You can call
Runtime.getRuntime().maxMemory()
in your code - You can look at the
java.lang:type=Memory
MBean via JMX - You can install a JDK inside your container and use
jinfo
viadocker exec
The third option looks like it's a bit problematic however... I can't actually get jinfo
to tell me anything, either as root
or as the jetty
user.
from docker-jetty.
With the latest jre8
images, it should also be possible to use Docker's cgroup-based memory limits to configure the heap using the -XX:+UseCGroupMemoryLimitForHeap
JVM option. See docker-library/openjdk#71 (comment)
Here's an example command that gives the container 600 megabytes and give the JVM half of that memory:
$ docker run -d -p 80:8080 -p 443:8443 --memory 600m \
-e JAVA_OPTIONS='-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -X:MaxRAMFraction=2'
I'm going to close this issue since the the way to set the heap size has been documented.
from docker-jetty.
Related Issues (20)
- Issues with Docker Build with 1.8.0_191 HOT 2
- Provide Jetty images based on openjdk:11-jre-slim HOT 7
- jetty:9-jre8 SSL no longer works, FIN sent in reply to CLIENT_HELLO HOT 7
- jetty user home is not properly set HOT 5
- sqlite (used in sqlite-libs) version 3.26.0-r3 has 2 vulnerabilities HOT 1
- Mail library included in jetty-jre11 is not compatible with JDK11 HOT 11
- Docker image for jetty 10 HOT 3
- TMPDIR /tmp/jetty not used
- Replace sks-keyservers.net HOT 9
- Discontinue building the image based on OpenJDK JRE 7 HOT 1
- Old version 9.4.18 in docker hub HOT 1
- Container exits immediately when using JDWP in JAVA_OPTIONS HOT 4
- Jetty on top of Openjdk-8 JDK version HOT 2
- Add jetty 9 images based on AdoptOpenJDK HOT 1
- Stop supporting deprecated versions of Jetty HOT 5
- Move official docker-jetty project to the jetty project HOT 3
- jetty 9.4.29 released HOT 1
- Empty jetty.start file HOT 5
- start.jar explodes: missing/invalid file modules/alpn-impl/alpn-1.8.0_181.mod HOT 4
- Any plans for jre11 ? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-jetty.