This post will discuss debugging a JAVA application running inside a container.
Red Hat container images # When you bootstrap your JVM, you should have a way to enable JVM to debug. For example, Red Hat S2I images allow you to control classpath and debugging via environment variables.
# Set debug options if required if [ x"${JAVA_DEBUG}" != x ] && [ "${JAVA_DEBUG}" != "false" ]; then java_debug_args="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=${JAVA_DEBUG_PORT:-5005}" fi Setting the JAVA_DEBUG environment variable inside the container to true will append debug args to the JVM startup command Configure port forwarding so that you can connect to your application from a remote debugger If you are using the tomcat image, replace the JAVA_DEBUG environment variable with DEBUG
Sometimes writing code that runs is not enough. We might want to know what goes on internally, such as memory allocation, consequences of using one coding approach over another, implications of concurrent executions, areas to improve performance, etc. We can use profilers for this.
In this post, I’ll discuss using YourKit-JavaProfiler inside a container.
Since my sample application is built using OpenShift S2I process and pushed into OpenShift internal registry, I’ll have to pull the image locally.