Increase memory allocated to application deployed to payara micro - jvm

Am running my application from a payara micro UberJar and would like to increase the memory allocated to the application. How can I do this at the point of creating the uberJar?

There are a couple of ways you can do this. The first way I'll mention is the preferred way:
1. Use asadmin commands
The latest edition of Payara Micro introduces an option called --postbootcommandfile which allows you to run asadmin commands against Payara Micro. Your file should include something like this:
delete-jvm-options -Xmx=512m
create-jvm-options -Xmx=1g
create-jvm-options -Xms=1g
You will need to make sure you delete the existing options before applying new ones.
You can then use the file similar to this:
java -jar payara-micro.jar --postbootcommandfile myCommands.txt --deploy myApp.war --outputuberjar myPayaraMicroApp.jar
Your settings should now persist in the resulting Uber JAR.
2. Supply a custom domain.xml
The alternative to this would be modifying a domain.xml of your own and overriding the in-built domain.xml with your own.
You can use the --rootdir option to get Payara Micro to output its configuration to a directory so you can make changes there. This process is outlined in this blog:
http://blog.payara.fish/working-with-external-configuration-files-in-payara-micro
If you already have a custom domain.xml to hand, you can use the --domainconfig property to supply it, as follows:
java -jar payara-micro.jar --domainconfig myCustomDomain.xml --deploy myApp.war --outputuberjar myPayaraMicroApp.jar
After following either of these methods, you can simply start the resulting JAR and all the settings and configuration will be applied:
java -jar myPayaraMicroApp.jar

Payara Micro uber JAR is a plain JAR and it doesn't start a new JVM like Payara Server does. Therefore there's no way to modify JVM memory settings from within the JAR as the JVM is already started. Although it's possible to add the JVM settings into the Payara Micro configuration, they are ignored and not applied. Those configuration values are only used within Payara Server.
With Payara Micro uber JAR, you need to specify the JVM options on the command line, like this:
java -Xmx=1g -Xms=1g -jar myPayaraMicroApp.jar
If you need to specify JVM arguments in the uber JAR, you need to use a solution like capsule.io to wrap the JAR into a launcher JAR that would spawn a separate JVM for Payara Micro and pass the arguments to it.

Related

Spring Profiles in combination with ConfigServer

I have a very basic Spring Boot Config Server (just added the dependency and annotated mainclass with #EnableConfigServer).
In general I would like to support multiple environments with different propertysources for each of my applications, here is the example of the ConfigServer itself:
Profile: default (application.yml on classpath):
Profile: docker (application-docker.yml on classpath):
Profile: default (application.yml in repository of ConfigServer):
So in my case all of the properties from all of the three screenshots should be active, I'd expect the order/priority as follows:
application.yml from classpath
application-ANY_PROFILE.yml from classpath
application.yml from config repo
APP-NAME.yml from config repo (does not exists in this case)
So far this works flawlessly, except the issue that I'm having is that my application-docker.yml on classpath is beeing ignored when I start the application with the command (of course inside the container):
java -jar -Dspring-boot.run.profiles=docker *.jar
as you can see here:
My question is, even when I provide the profile as command line argument its not beeing picked up.
Why is that?
UPDATE, here is the Dockerfile and entrpoint.sh:
To activate one or more profiles do one of the following:
Activate using the VM parameters -Dspring.profiles.active=<profiles>
Activate using program arguments --spring.profiles.active=<profiles>
Following your example, the following should work:
java -jar -Dspring.profiles.active=docker *.jar

JavaMelody error - Monitoring of sql requests and of jdbc connections in GlassFish v4.1

I want to use JavaMelody to monitor the SQL requested by a Glassfish Application Server. There are step-by-step instructions on https://github.com/javamelody/javamelody/wiki/UserGuideAdvanced#monitoring-of-sql-requests-and-of-jdbc-connections-in-glassfish-v3
I followed the instructions (I didn't download javamelody-objectfactory.jar but used javamelody-core-1.54.0.jar instead) and I get this error when clicking on the refresh button (javamelody web page) :
server.log :
exception while collecting data
java.lang.NoClassDefFoundError: org/jrobin/core/RrdException
at net.bull.javamelody.Collector.getCounterJRobin(Collector.java:836)
at net.bull.javamelody.Collector.collectJRobinValues(Collector.java:489)
...
any idea how to resolve this ?
jrobin-1.5.9.1.jar is installed in the lib folder of glassfish (and in my ear project).
thanks !
javamelody-objectfactory.jar (java source included in the jar) and javamelody-core jar file are absolutely different things. The first is to make the datasource monitorable in Glassfish and the second is the monitoring tool itself.
First fix the exception. You should probably put javamelody-core jar and jrobin jar files in your ear project (and not one in lib folder of Glassfish and one in ear).
Then if the monitoring reports don't include SQL monitoring for the datasource declared in Glassfish, use the javamelody-objectfactory.jar including all steps as said in the doc.

Error initializing JVM

I am getting "Could not reserve enough space for object heap" error when I am trying to start hybris server.
I have set
wrapper.java.additional.1=-Xmx1G
wrapper.java.additional.2=-XX:MaxPermSize=1024M
My machine is 64 bit 8GB RAM Windows
I faced the same problem once, The problem in my case was that too many other Applications were running on my system.
So go to the task manager and check the memory available use.
Close some applications and try running.
Also if you are using eclipse Then, In your eclipse.ini file (this is beside the eclipse executable), replace -Xmx256m with -Xmx1024m (or Xmx512m).
This is not compulsory but in certain cases it works.
If you are using some extension then,
Open YOURPATH/config/local.properties file.
Add the following entry:
config/local.properties
build.parallel=true
Save the file.
(In cases where we have multiple cores in the machine, we can tell hybris to utilize these by building in parallel and in certain cases this too works)
I too faced the same probelm. I followed below steps and set the max heap size to 1GB.
Add the following content to local.properties
tomcat.generaloptions=-Xmx4G -ea -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=true -Djava.endorsed.dirs="%CATALINA_HOME%/lib/endorsed" -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Dfile.encoding=UTF-8 -Dlog4j.configuration=log4j_init_tomcat.properties -Djava.util.logging.config.file=jdk_logging.properties -Djava.io.tmpdir="${HYBRIS_TEMP_DIR}"
ant clean all
start hybrisserver
Reference
https://launchpad.support.sap.com/#/notes/0002437669

Weblogic forces recompile of EJBs when migrating from 9.2.1 to 9.2.3

I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)

How do I start my Java program with more than one java agent?

I'm aware of how to start a java progam with a java agent:
java -javaagent:myAgent.jar MyJavaProgram
But what if I want to add 2 or more java agents to instrument my program? I do not want to reinvoke the java -javaagent:... for every agent I have to load in JVM.
I've tried something like this :
java -javaagent:agentA.jar, agentB.jar MyJavaProgram
or something like this:
java -javaagent:agentA.jar agentB.jar MyJavaProgram
But have no success.
Is there an answer to solve my problem ?
Thank you.
How about two javaagent parameters?
java -javaagent:agentA.jar -javaagent:agentB.jar MyJavaProgram
It would appear you can do this by using multiple arguments. From the documentation:
On implementations with a command-line interface, an agent is started by adding this option to the command-line:
-javaagent:jarpath[=options]
jarpath is the path to the agent JAR file. options is the agent options. This switch may be used multiple times on the same command-line, thus creating multiple agents. More than one agent may use the same jarpath. An agent JAR file must conform to the JAR file specification.
(my emphasis)
Adding to the above answers, if you are using ant and want to include <jvmargs /> with more than one jar to -javaagent to start the server, here's how I did it,
build.xml
<target name="blah">
...
<jvmarg value="-javaagent:${jar1.path}" />
<jvmarg value="-javaagent:${jar2.path}" />
...
</target>
There is a new project with the goal to support multiple Java agents. Currently it is limited to specific ones.
Agent Bond is a super agent, which wraps and dispatches on several other agents. That way, you only have to install a single agent within your JVM with a single set of configuration data (which contains multiple separate parts).
See https://github.com/fabric8io/agent-bond/blob/master/README.md for details