We Keep Coding

Integration of JMX in Wildfly

I have been meaning to monitor my wildfly in zabbix through JMX. The versions are listed below
wildfly: 20.0.0.1 final
zabbix: 5.0.7
java(that is present in wildfly host): openjdk version "11.0.8" 2020-07-14
The issue i am facing while i run wildlfy is as follows.
-Xbootclasspath is no longer a supported option. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit
My standalone.conf file looks like as below:
if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.bytemani,org.joss.logmanager"
fi
# Uncomment the following line to prevent manipulation of JVM options
# by shell scripts.
#
#PRESERVE_JAVA_OPTS=true
#
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms2G -Xmx2G -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=1G -Djava.net.preferIPv4Stack=true"
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath:/opt/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.15.Final.jar"
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
else
echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
fi
As per my research, i have found that my java version is not compatible and i dont know the work around process.

Docker buildx Errors, but Docker build works

I'm attempting to build an image for my application using a multi-stage Dockerfile with Gradle and OpenJDK as base images.
Here's the Dockerfile:
ARG JAVA_VERSION
FROM gradle:7.5.1 as build
# Change the work directory to the app root
WORKDIR /app
# Copy all source contents to the build directory
COPY . .
# Execute the build
RUN gradle build
# Create a production stage
FROM openjdk:${JAVA_VERSION}-slim as app
# Change the work directory to the app root
WORKDIR /app
# Declare the version for use in the next step
ARG APP_VERSION
# Copy the JAR from the build directory in the previous stage
COPY --from=build /app/build/libs/app-jvm-$APP_VERSION.jar app-$APP_VERSION.jar
# Execute the startup command
CMD [ "java", "-jar", "app-$APP_VERSION.jar" ]
The script I'm using to export environment variables an subsequently run the buildx bake command is:
#!/bin/bash
# shellcheck disable=SC2046
#
# This script is intended to deploy all Docker images to the registry
# 1. Read all build environment variables from .env
# 2. Login to the Docker registry
# 3. Build and push all images with Docker buildx
#
# Export all the environment variables that are present in .env
echo "Exporting all variables from .env"
export $(grep -v '^#' .env | xargs -d '\n')
# Login to the registry if it ends in .com
if [[ $REGISTRY == *.com ]]; then
echo "Logging in to https://$REGISTRY Docker registry"
docker login https://"$REGISTRY"
fi
# Build and push with buildx bake using the docker compose file
echo "Building and pushing images"
docker buildx bake -f docker-compose.yml --push
When building the image with docker compose build, everything works.
The issue is that when running the script (or the command directly after exporting the variables), an error is produced at unusual places.
With the Dockerfile above, running the command produces the following error (FYI making the variable explicit changes nothing either):
--------------------
14 |
15 | # Create a production stage
16 | >>> FROM openjdk:${JAVA_VERSION}-slim as app
17 |
18 | # Change the work directory to the app root
--------------------
error: failed to solve: openjdk:17.0.2-slim: no match for platform in manifest sha256:aaa3b3cb27e3e520b8f116863d0580c438ed55ecfa0bc126b41f68c3f62f9774: not found
If I change the base image to some other Java based image such as gradle:7.5.1, then I get another error:
------
> [app linux/arm/v7 build 4/4] RUN gradle build:
#0 1.199 org.gradle.api.internal.classpath.UnknownModuleException: Cannot locate JAR for module 'ant' in distribution directory '/opt/gradle'.
#0 1.202 at org.gradle.api.internal.classpath.DefaultModuleRegistry.loadExternalModule(DefaultModuleRegistry.java:109)
#0 1.202 at org.gradle.api.internal.classpath.DefaultModuleRegistry.getExternalModule(DefaultModuleRegistry.java:97)
#0 1.202 at org.gradle.api.internal.DefaultClassPathProvider.findClassPath(DefaultClassPathProvider.java:70)
#0 1.202 at org.gradle.api.internal.DefaultClassPathRegistry.getClassPath(DefaultClassPathRegistry.java:35)
#0 1.202 at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:48)
#0 1.203 at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
#0 1.203 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
#0 1.203 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
#0 1.203 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
#0 1.203 at java.base/java.lang.reflect.Method.invoke(Method.java:568)
#0 1.204 at org.gradle.launcher.GradleMain.main(GradleMain.java:34)
------
--------------------
9 |
10 | # Execute the build
11 | >>> RUN gradle build
12 |
13 | # Create a production stage
--------------------
error: failed to solve: process "/bin/sh -c gradle build" did not complete successfully: exit code: 1
Further examination of the gradle:7.5.1 image reveals that /opt/gradle DOES indeed have ant modules available.
Since the build is successful and none of these issues show themselves when running docker compose build, it seems that this has to do with buildx.
I'm running Windows 10 with WSL Debian. Note that I've also tried restarting docker, clearing caches, enabling experimental mode and even running it on a different machine (an Ubuntu server).
If anyone has any insight or possible solution I'd appreciate it!
EDIT:
I've realized that I completely missed the platform error on arm/v7 for OpenJDK. Looks like there isn't an OpenJDK image for arm/v7 and leaving me having to use eclipse-temurin.
The Gradle error is similar in that the ant module may be missing for the specific arm/v7 image. However, I'm unsure how to get past that particular issue other than possibly installing ant on the Gradle image if there is an arm/v7 version.

Java api running in wildfly stopped responding

I have a java api service deployed in wildfly on Amazon linux, randomly the api calls are not reaching the api-service at all, but the wildfly is up and running, the memory/cpu usage seems normal at this point. I couldn't see any error on the application log.
When I restart wildfly, the application work normally.
Any pointers to debug this issue? Thank you
Wildfly Configuration
# General configuration for the init.d scripts,
# not necessarily for JBoss AS itself.
# default location: /etc/default/wildfly
## Location of JDK
JAVA_HOME="/usr/"
## Location of WildFly
JBOSS_HOME="/opt/wildfly"
## The username who should own the process.
JBOSS_USER=root
## The mode WildFly should start, standalone or domain
JBOSS_MODE=standalone
## Configuration for standalone mode
JBOSS_CONFIG=standalone.xml
## Configuration for domain mode
# JBOSS_DOMAIN_CONFIG=domain.xml
# JBOSS_HOST_CONFIG=host-master.xml
## The amount of time to wait for startup
STARTUP_WAIT=60
## The amount of time to wait for shutdown
SHUTDOWN_WAIT=60
## Location to keep the console log
JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log"
## Additionals args to include in startup
# JBOSS_OPTS="--admin-only -b 127.0.0.1"
JBOSS_OPTS="-Djboss.bind.address=xxx.xxx.xxx.xxx -DConfig=/opt/app-conf/app-conf.properties -DLogDirectory=/var/log/wildfly"
Here is the output of ps -ef | grep wildfly
/usr//bin/java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -Djboss.bind.address=xxx.xxx.xxx.xxx -DConfig=/opt/app-conf/app-conf.properties -DLogDirectory=/var/log/wildfly
Can you help to check if the memory and heap space are right? Or should I increase what could be the optimal value for it?

Android Studio1.5 Error occurred during initialization of VM Could not reserve enough space for object heap

When I run my project ,error comes.
Starting process 'command 'C:\Java\jdk1.7.0\bin\java.exe''. Working directory: C:\Users\john\AndroidStudioProjects\Prefs\app Command: C:\Java\jdk1.7.0\bin\java.exe -Djava.awt.headless=true -Xmx1024M -Dfile.encoding=UTF-8 -Duser.country=CN -Duser.language=zh -Duser.variant -cp C:\Users\john\AppData\Local\Android\sdk1\build-tools\21.1.2\lib\dx.jar com.android.dx.command.Main --dex --verbose --output C:\Users\john\AndroidStudioProjects\Prefs\app\build\intermediates\pre-dexed\debug\com.android.support-support-v4-21.0.3_42a7fe41e85c69c43b7a4dd1dda945656e9dd165.jar C:\Users\john\AndroidStudioProjects\Prefs\app\build\intermediates\exploded-aar\com.android.support\support-v4\21.0.3\jars\classes.jar
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.Error: A fatal exception has occurred. Program will exit.:app:transformClassesWithDexForDebug FAILED:app:transformClassesWithDexForDebug (Thread[Daemon worker Thread 8,5,main])completed. Took 0.549 secs.
I set .gradel.properties and gradle can be rebuilt and cleaned
org.gradle.jvmargs=-Xmx512m -XX:MaxPermSize=128m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
In C:\User\john\.gradle\daemon\2.8\gradle.properties I set
org.gradle.jvmargs=-Xms256m -Xmx512m
Environment
os:windows7 RAM:4G JVM:1.7 android studio 1.5
Why the command of 'java.exe -Xmx1024m' is run.When I change this command to "-Xmx512m" and run in the command line ,this command was execute successfully.
How reduce the jvm in this command. I search the issue in SO much times buy not solve the question.
Please help me ,thanks a lot.

Jenkins Java VM error when running a Maven test - Unrecognized VM option 'MaxPermSize-128m'

The problem is, we changed that from MaxPermSize-128m to MaxPermSize=128m
but the system keeps giving us that error:
We even restarted Jenkins.
Is it caching something, or there is more than one place where this setting should be changed?
[workspace] $ /usr/lib/jvm/java-6-openjdk-amd64/bin/java -Xmx512m -XX:MaxPermSize-128m -cp /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.3.jar:/mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0/boot/plexus-classworlds-2.4.2.jar org.jvnet.hudson.maven3.agent.Maven3Main /mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0 /var/cache/jenkins/war/WEB-INF/lib/remoting-2.28.jar /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.3.jar 55896
Unrecognized VM option 'MaxPermSize-128m'
Could not create the Java virtual machine.
ERROR: Failed to launch Maven. Exit code = 1
the output of 'ps -ef | grep java' is:
root 3509 1 0 Jul12 ? 00:07:17 /usr/local/share/elasticsearch/bin/service/exec/elasticsearch-linux-x86-64 /usr/local/share/elasticsearch/bin/service/elasticsearch.conf wrapper.syslog.ident=elasticsearch wrapper.pidfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.pid wrapper.name=elasticsearch wrapper.displayname=ElasticSearch wrapper.daemonize=TRUE wrapper.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.status wrapper.java.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.java.status wrapper.script.version=3.5.14
root 3511 3509 0 Jul12 ? 00:45:11 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java -Delasticsearch-service -Des.path.home=/usr/local/share/elasticsearch -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -Djava.awt.headless=true -Xms1024m -Xmx1024m -Djava.library.path=/usr/local/share/elasticsearch/bin/service/lib -classpath /usr/local/share/elasticsearch/bin/service/lib/wrapper.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/jna-3.3.0.jar:/usr/local/share/elasticsearch/lib/log4j-1.2.17.jar:/usr/local/share/elasticsearch/lib/lucene-analyzers-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-core-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-highlighter-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-memory-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-queries-3.6.1.jar:/usr/local/share/elasticsearch/lib/snappy-java-1.0.4.1.jar:/usr/local/share/elasticsearch/lib/sigar/sigar-1.6.4.jar -Dwrapper.key=b1QUXxfrVfakmb6w -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=3509 -Dwrapper.version=3.5.14 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp org.elasticsearch.bootstrap.ElasticSearchF
jenkins 20372 1 0 08:17 ? 00:00:00 /usr/bin/daemon --name=jenkins --inherit --env=JENKINS_HOME=/mnt/www/jenkins --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/jenkins/jenkins.pid -- /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
jenkins 20373 20372 23 13:20 ? 00:05:51 /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
root 29403 28220 0 13:45 pts/0 00:00:00 grep --color=auto java

How did you expect to set the maximum to a negative value? I think you wanted
-XX:MaxPermSize=128m
-- Update ---
Ok, so you have fixed this, but the build still fails.
Look into the "workspace cleanup plugin", and if it is not installed, install it and activate it. The workspace cleanup plugin will remove evidence of prior builds from the workspace before launch. Odds are that the configuration is stored to file, and then referenced from file immediately prior to launch.
You could move into the workspace directories and grep for the "minus 128" version of the command and alter it by hand, but by using the plugin you also avoid future similar issues.