We are planning on using JDK 1.8 for Mule 3.7 CE.
In the past we edited wrapper.conf to tweak the memory JDK 1.6/1.7 uses. We did this by editing:
wrapper.java.initmemory=256m
wrapper.java.maxmemory=512
wrapper.java.additional.7=-XX:PermSize=256m
wrapper.java.additional.8=-XX:MaxPermSize=512m
Looking into the processes that are running in linux we see that Mule still uses xmx settings. If not mistaken, this no longer works in java 1.8 because it has been removed. Instead JDK 1.8 uses metaspace.
Now my question is, how/where to we make memory tweaks for Mule 3.7 using JDK 1.8? Or does Mule 3.7 CE not support this yet?
Do we simply add to wrapper.conf the following settings?:
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
And remove:
wrapper.java.initmemory=1024
wrapper.java.maxmemory=1024
Or we do still use the following settings?
wrapper.java.initmemory
wrapper.java.maxmemory?
Thanks!
You can keep using the initmemory and maxmemory.
Changing to Java 1.8 doesn't impact this.
We use Java 1.8 with Mule 3.7 in Linux and we are able to successfully control the heap allocation with the current setting of initmemory and maxmemory.
You might want to use Metaspace configuration only to replace PermGen settings.
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
Go through the following link for more understanding.
http://www.infoq.com/articles/Java-PERMGEN-Removed
Hope this helps.
Related
I am currently involved in a project, that requires migration of 3.5 to 4.x, 4.14 is working fine. I am raising this question because, mule 2 is supporting Java 11, while mule recommended approach is to work on adoptopenjdk 8.0
https://docs.mulesoft.com/release-notes/mule-runtime/mule-4.2.0-release-notes
It is not clear exactly what is the question, however migrating from Mule 4.1.x to 4.2.x doesn't require usually changes to applications. You are free to use Java 8 or 11, though 8 is recommended.
You can upgrade from 4.1 to 4.2 without changing the code or the java version.
So the best approach to migrate would be to use the same configuration as in 4.1
Furthermore, it's a good practice to upgrade the connectors versions of your app.
We have a legacy system that runs on Coldfusion 6.1 with JVM 1.6.0 build 24. It appears that TLSv 1.1 was added in build 111. Is it possible to get Coldfusion 6.1 to work with that build (or higher) and what would I have to do?
TLS 1.1 is only supported in Java 1.8 on CF10 (Oddly 1.7 and above in CF11)
I dont think CF 6.1 will work properly on higher versions of JDK. You may want to try to upgrade it to 1.8 to see if that helps.
See this Adobe Blog as a starting guide to updating your Java: http://blogs.coldfusion.com/post.cfm/how-to-change-upgrade-jdk-version-of-coldfusion-server
Also see this: http://www.coldfusionmuse.com/index.cfm/2014/12/8/colfusion-jvm-versions-sslv3-tls
I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.
Is there a way we can specify the JDK version we are running on? Specifically, I have a java app (non webapp) that has an incompatibility with 1.6.0_35 and is erroring out for me on CloudBees. The package recommends 1.6.0_27, is that possible to specify at deployment time?
you can specify the version with -Rjava_version on the command line - however, fine grained versions are not available (as we tend to update those) - it is more just 1.6, 1.7 or 1.8 lineage. I would recommend in that case -Rjava_version=1.7.
is there anyway that I can take a heap dump using java 1.4.1 on Solaris 9?
I'm using a very old application server and java version and would like to take a heap dump.
I'm gonna use it on production so hprof may not be an option. Is there any tools that I could install ?
Thanks
There seem to be bugs with HPROF for JDKs 1.4 and 1.4.1
Warning: JDK 1.4 and JDK 1.4.1 contains a bug in hprof. You cannot use these versions with HAT.
so you may consider upgrading to latest update from JDK 1.4.2
This way you could use backported jmap for Solaris to take a heap dump like described here.